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(54) Optimum routing system 

(57) A wireless data network includes a wireless 
packet switched data network for end users that divides 
mobility management into local, micro, macro and glo- 
bal connection handover categories and minimizes 
handoff updates according to the handover category. 
The network integrates MAC handoff messages with 
network handoff messages. The network separately di- 
rects registration functions to a registration server and 
direct routing functions to inter-working function units. 



The network provides an intermediate XTunnel channel 
between a wireless hub (also called access hub AH) and 
an inter-working function unit (I WF unit) in a foreign net- 
work, and it provides an I XTunnel channel between an 
inter-working function unit in a foreign network and an 
inter-working function unit in a home network. The net- 
work enhances the layer two tunneling protocol (L2TP) 
to support a mobile end system, and it performs network 
layer registration before the start of a PPP communica- 
tion session. 



FIG. 2 
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Description 

Background of the Invention 
Field of the Invention 

[0001] The present invention relates to the manage- 
ment of mobile end systems in a packet switched data 
network that provides computer users with remote ac- 
cess to the internet and to private intranets using virtual 
private network services over a high speed, packet 
switched, wireless data link. In particular, the invention 
relates the optimization of routing mobile end systems 
to desired communications servers. 

Description Of Related-Art _ 



ration which owns and operates its own private intranet 
18 through router 12B for business reasons. Corporate 
employees may access corporate network 1 8 (e.g., from 
home or while on the road) by making POTS/ISDN calls 
s to corporate remote access server 16 and running the 
IETF PPP protocol. For corporate access, end users on- 
ly pay for the cost of connecting to corporate remote ac- 
cess server 16. The ISP is not involved. The private cor- 
poration maintains router 12B to connect an end user to 
io either corporate intranet 1 8 or public internet 20 or both. 
[0006] End users pay the telco for the cost of making 
phone calls and for the cost of a phone line into their 
home. End users also pay the ISP for accessing the 
ISP's network and services. The present invention will 
is benefit wireless service providers like Sprint PCS, 
-PrimeGo r ete~and benetit-internet-service-providers-|ike~ 



[0002] FIG. 1 depicts three business entities, whose 
equipment, working together typically provide remote in- 
ternet access to user computers 2 through user mo- 
dems 4. User computers 2 and modems 4 constitute end 
systems. 

[0003] The first business entity is the telephone com- 
pany (telco) that owns and operates the dial-up plain old 
telephone system (POTS) or integrated services data 
network (ISDN) network. The telco provides the media 
in the form of public switched telephone network (PSTN) 
6 over which bits (or packets) can flow between users 
and the other two business entities. 
[0004] The second business entity is the internet serv- 
ice provider (ISP). The ISP deploys and manages one 
or more points of presence (POPs) 8 in its service area 
to which end users correct for network service. An ISP 
typically establishes a POP in each major local calling 
area in which the ISP expects to subscribe customers. 
The POP converts message traffic from the PSTN run 
by the telco into a digital form to be carried over intranet 
backbone 10 owned by the ISP or leased from an in- 
tranet backbone provider like MCI, Inc. An ISP typically 
leases fractional or full T1 lines or fractional or full T3 
lines from the telco for connectivity to the PSTN. The 
POPs and the ISP's medium data center 14 are con- 
nected together over the intranet backbone through 
router 12A. The data center houses the ISP's web serv- 
ers, mail servers, accounting and registration servers, 
enabling the ISP to provide web content, e-mail and web 
hosting services to end users. Future value added serv- 
ices may be added by deploying additional types of serv- 
ers in the data center The ISP also maintains router 1 2A 
to connect to public internet backbone 20. In the current 
model for remote access, end users have service rela- 
tionships with their telco and their ISP and usually get 
separate bills from both. End users access the ISP, and 
through the ISP, public internet 20, by dialing the nearest 
POP and running a communication protocol known as 
the Internet Engineering Task Force (IETF) point-to- 
point protocol (PPP). 

[0005] The third business entity is the private corpo- 



50 



AOL, AT&T Worldnet, etc. 
[0007] Today, internet service providers offer internet 
access services, web content services, e-mail services, 

20 content hosting services and roaming to end users. Be- 
cause of low margins and no scope of doing market seg- 
mentation based on features and price, ISPs are looking 
for value added services to improve margins. In the 
short term, equipment vendors will be able to offer so- 

25 lutions to ISPs to enable them to offer faster access, vir- 
tual private networking (which is the ability to use public 
network securely as private networks and to connect to 
intranets), roaming consortiums, push technologies and 
quality of service. In the longer term, voice over internet 

30 and mobility will also be offered. ISPs will use these val- 
ue added services to escape from the low margin strait- 
jacket. Many of these value added services fall in the 
category of network services and can be offered only 
through the network infrastructure equipment. Others 

35 fail in the category of application services which require 
support from the network infrastructure, while others do 
not require any support from the network infrastructure. 
Services like faster access, virtual private networking, 
roaming, mobility, voice, quality of service, quality of 

40 service based accounting all need enhanced network 
infrastructure. The invention described here will be ei- 
ther directly provide these enhanced services or provide 
hooks so that these services can be added later as fu- 
ture enhancements. Wireless service providers will be 

45 able to capture a larger share of the revenue stream. 
The ISP will be able to offer more services and with bet- 
ter market segmentation. 



SUMMARY OF THE INVENTION 



[0008] The present invention provide end users with 
remote wireless access to the public internet, private in- 
tranets and internet service providers. Wireless access 
is provided through base stations in a home network and 
55 base stations in foreign networks with interchange 
agreements. The optimum route between the serving in- 
ter-working function and the desired communication 
server is determined. 
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[0009] It is an object of the present invention to pro- 
vide a wireless packet switched data network for end 
users that divides mobility management into local, mi- 
cro, macro and global connection handover categories 
and minimizes handoff updates according to the hando- s 
ver category. It is another object to integrate MAC hand- ' 
off messages with network handoff messages. It is a fur- 
ther object of the present invention to separately direct 
registration functions to a registration server and direct 
routing functions to inter-working function units. It is yet io 
another object to provide an intermediate XTunnel chan- 
nel between a wireless hub (also called access hub AH) 
and an inter-working function unit (I WF unit) in a foreign 
network. It is yet another object to provide an IXTunnel 
channel between an inter-working function unit in a for- is 
eign network and an inter-working function unit in a 
home network. It is yet another object to enhance the 
layer two tunneling protocol (L2TP) to support a mobile 
end system. It is yet another object to perform network 
layer registration before the start of a PPP communica- 2a 
tion session. 

[0010] These and other objects are achieved in a net- 
work that includes a home network, a foreign network 
and an end station. The foreign network includes a base 
station and a foreign mobile switching center with a serv- 25 
ing registration server. The base station including an ac- 
cess hub with serving inter-working function. The home 
network includes a home mobile switching center with 
a home registration server and a home inter-working 
function. The end system subscribes to the home net- 30 
work and operates within the foreign network. The end 
system includes an end registration agent to form a reg- 
istration request. The registration request includes an 
indication of a desired communications network having 
a desired communications server. The end system 35 
sends the registration request to the serving registration 
server. The serving registration server includes a first 
module to process the registration request and to deter- 
mine an optimum route between the desired communi- 
cations server and one of the home inter-working tunc- 40 
tion and the serving inter-working function. The serving 
registration server further includes a second module to 
link the serving inter-working function to the desired 
communications server when the first module deter- 
mines that the optimum route is between the serving in- 45 
ter-working function and the desired communications 
server. 
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BRIEF DESCRIPTION OF DRAWINGS 

[0011] The invention will be described in detail in the 
following description of preferred embodiments with ref- 
erence to the following figures wherein: 



FIG. 1 is a configuration diagram of a known remote ss 
access architecture through a public switched tele- 
phone network; 

FIG. 2 is a configuration diagram of a remote access 



architecture through a wireless packet switched da- 
ta network according to the present invention; 
FIG. 3 illustrates an end system configuration ac- 
cording to one embodiment of the present inven- 
tion; 

FIG, 4 illustrates another end system configuration 
according to one embodiment of the present inven- 
tion; 

FIG. 5 illustrates another end system configuration 
according to one embodiment of the present inven- 
tion; 

FIG. 6 is a configuration diagram of selected parts 
of the architecture of the network of FIG. 2 showing 
a roaming scenario; 

FIG. 7 is a configuration diagram of a base station 
with local access points; 

FIG. 8 is a configuration diagram of a base station 
with remote access points; 

FIG. 9 is a configuration diagram of a base station 
with remote access points, some of which are con- 
nected using a wireless trunk connection; 
FIG. 10 is a diagram of a protocol stack for a local 
access point; 

FIG. 1 1 is a diagram of a protocol stack for a remote 
access point with a wireless trunk; 
FIG. 12 is a diagram of a protocol stack for a relay 
function in the base station for supporting remote 
access points with wireless trunks; 
FIG. 13 is a diagram of protocol stacks for imple- 
menting the relay function depicted in FIG. 12; 
FIG. 14 is a diagram of protocol stacks for a relay 
function in the base station for supporting local ac- 
cess points; 

FIG. 15 is a configuration diagram of selected parts 
of the architecture of the network of FIG. 2 showing 
a first end system registering in the home network 
from the home network and a second system reg- 
istering in the home network from a foreign network 
using a home inter-working function for an anchor; 
FIG. 16 is a configuration diagram of selected parts 
of the architecture of the network of FIG. 2 showing 
a first end system registering in the home network 
from the home network and a second system reg- 
istering in the home network from a foreign network 
using a serving inter-working function for an anchor; 
FIG. 17 is a ladder diagram of the request and re- 
sponse messages to register in a home network 
from a foreign network and to establish, authenti- 
cate and configure a data link; 
FIG. 18 is a configuration diagram of selected parts 
of the architecture of the network of FIG. 2 showing 
registration requests and responses for registering 
a mobile in a home network from the home network; 
FIG. 19 is a configuration diagram of selected parts 
of the architecture of the network of FIG. 2 showing 
registration requests and responses for registering 
a mobile in a home network from a foreign network; 
FIG . 20 is a configuration diagram of protocol stacks 
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showing communications between an end system 
in a home network and an inter-working function in 
the home network where the cell site has local ac- 
cess points; 

FIG. 21 is a configuration diagram of protocol stacks 
showing communications between an end system 
in a home network and an inter-working function in 
the home network where the cell site has remote 
access points coupled to a wireless hub through a 
wireless trunk; 

FIG. 22 is a configuration diagram of protocol stacks 
showing communications between a base station 
coupled to a roaming end system and a home inter- 
working function; 

FIG. 23 is a configuration diagram of protocol stacks 
^„showing-communications-between-an-end-system- 
in a home network through an inter-working function 
in the home network to an internet service provider; 
FIG.24 is a configuration diagram of protocol stacks 
showing communications between an end system 
in a foreign network and a home registration server 
in a home network during the registration phase; 
FIG. 25 is a processing flow diagram showing the 
processing of accounting data through to the cus- 
tomer billing system; 

FIGS. 26 and 27 are ladder diagrams depicting the 
registration process for an end system in a home 
network and in a foreign network, respectively; 
FIGS. 28 and 29 are protocol stack diagrams de- 
picting an end system connection in a home net- 
work where a PPP protocol terminates in an inter- 
working function of the home network and where 
the PPP protocol terminates in an ISP or intranet, 
respectively; 

FIGS. 30 and 31 are protocol stack diagrams de- 
picting an end system connection in a foreign net- 
work where a PPP protocol terminates in an inter- 
working function of the foreign network and where 
the PPP protocol terminates in an ISP or intranet, 
respectively; 

FIGS. 32, 33 and 34 are ladder diagrams depicting 
a local handoff scenario, a micro handoff scenario 
and a macro handoff scenario, respectively: 
FIG. 35 is a ladder diagram depicting a global hand- 
off scenario where the foreign registration server 
changes and where home inter-working function 
does not change; 

FIG. 36 is a ladder diagram depicting a global hand- 
off scenario where both the foreign registration 
server and the home inter-working function change; 
FIGS. 37 and 38 are system configuration diagrams 
which illustrate possible connections; and 
FIGS. 39-42 illustrates various handoff scenarios. 
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DETAILED DESCRIPTION OF PREFERRED 
EMBODIMENTS 

[0012] The present invention provides computer us- 



ss 



ers with remote access to the internet and to private in- 
tranets using virtual private network services over a high 
speed, packet switched, wireless data link. These users 
are able to access the public internet, private intranets 
and their internet service providers over a wireless link. 
The network supports roaming, that is, the ability to ac- 
cess the internet and private intranets using virtual pri- 
vate network services from anywhere that the services 
offered by the present invention are available, The net- 
work also supports handoffs, that is, the ability to change 
the point of attachment of the user to the network without 
disturbing the PPP link between the PPP client and the 
PPP server. The network targets users running horizon- 
tal internet and intranet applications. These applications 
include electronic mail, file transfer, browser based 
~WWW-access -and-other-business-applications^built" 
around the internet. Because the network will be based 
on the IETF standards, it is possible to run streaming 
media protocols like RTP and conferencing protocols 
like H.323 over it. 

[0013] Other internet remote access technologies 
that are already deployed or are in various stages of de- 
ployment include: wire line dial-up access based on 
POTS and ISDN, XDSL access, wireless circuit 
switched access based on GSM/CD MA/TDM A, wire- 
less packet switched access based on GSM/CDMA/TD- 
MA, cable modems; and satellite based systems. How- 
ever, the present invention offers a low cost of deploy- 
ment, ease of maintenance, a broad feature set, scale- 
ability, an ability to degrade gracefully under heavy load 
conditions and support for enhanced network services 
like virtual private networking, roaming, mobility and 
quality of service to the relative benefit of users and 
service providers. 

[0014] For wireless service providers who own per- 
sonal communications system (PCS) spectrum, the 
present invention will enable them to offer wireless 
packet switched data access services that can compete 
with services provided by the traditional wire line telcos 
who own and operate the PSTN. Wireless service pro- 
viders may also decide to become internet service pro- 
viders themselves, in which case, they will own and op- 
erate the whole network and provide end to end services 
to users. 

[0015] For internet service providers the present in- 
vention will allow them to by-pass the telcos (provided 
they purchase or lease the spectrum) and offer direct 
end to end services to users, perhaps saving access 
charges to the telcos, which may increase in the future 
as the internet grows to become even bigger than it is 
now. 

[0016] The present invention is flexible so that it can 
benefit wireless service providers who are not internet 
service providers and who just provide ISP, internet or 
private intranet access to end users. The invention can 
also benefit service providers who provide wireless ac- 
cess and internet services to end users. The invention 
can also benefit service providers who provide wireless 
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access and internet services but also allow the wireless 
portion of the network to be used for access to other 
ISPs or to private intranets. 

[0017] In FIG, 2, end systems 32 (e.g., based on, for 
example, Win 95 personal computer) connect to wire- 
less network 30 using external or internal modems. 
These modems allow end systems to send and receive 
medium access control (MAC) frames over air link 34. 
External modems attach to the PC via a wired or wire- 
less link. External modems are fixed, and, for example, 
co-located with roof top mounted directional antennae. 
External modems may be connected to the user's PC 
using any one of following means: 802.3, universal se- 
rial bus, parallel port, infra-red, or even an ISM radio 
link. Internal modems are preferably PCMCIA cards for 
laptops and are plugged into the laptop's backplane. Us- 
ing a small omni-directional antenna, they send and re- 
ceive MAC frames over the air link. 
[001 8] The end system consists of the equipment that 
is located at the subscribers location. In the case of a 
fixed installation, the end system consists of a rooftop 
mounted antenna, radio components, digital compo- 
nents, and finally a desktop computer. It is presumed 
that a subscriber will already own the desktop computer, 
thus the wireless system must connect to the PC 
through standard interfaces. Figures 3-5 illustrate the 
different options for typical fixed installations of the wire- 
less system. Each of the choices outlined in these fig- 
ures have consequences associated with them, ranging 
from installation costs, equipment costs, practical instal- 
lation to environmental with the installation, which will 
be discussed below. 

[0019] The installation show in Figure 3 is presently 
the least expensive. In this configuration, only an anten- 
na 21 is located outdoors and an RF cable 22 is con- 
nected to the radio 23. The installer, either the paid pro- 
fessional or the subscriber, will only have to install the 
antenna 21 at the roof or on the side of the building, and 
drop an inexpensive external cable 22 alongside the 
building to an entry point, typically through a hole in the 
corner of a window frame or through a hole in the wall 
near an internal floor. The radio 23 is external to the 
desktop computer 24 with a PCMCIA interface to the PC 
24. Losses in long RF cable runs for users located at 
distant points from the access point can be compensat- 
ed for with in-line bi-directional RF amplifiers. Users 
close to an access point can tolerate the additional loss- 
es of long cable runs since their propagation losses will 
not be as large as users at the periphery of the cell. 
[0020] Another design illustrated in Figure 4 involves 
integrating the radio electronics and the antenna into a 
common device 25. The connection to the PC 24 would 
be through a proprietary interlace and PCMCIA. Power 
would be supplied to the device from a wall tansformer 
27 via a multi twisted-paired cable 26 carrying both pow- 
er and digital data. The challenge of designing an inte- 
grated device includes weatherp roofing, heating and 
cooling, and server temperature extremes. 



[0021] Another design which consists of an outdoor 
antenna and an attic mounted subscriber unit. This al- 
leviated some of the low temperature and weatherproof - 
ing requirements, however, cooling will need to be pro- 
•5 vided. The subscriber unit is then connected to the PC 
via a cable. 

[0022] The last and most expensive means by which 
to move the digital data from the radio to a computer, or 
multiple computers, is to use an ISM band LAN, such 

to as WaveLAN as illustrated in Figure 5. The antenna 21 
will be located on the rooftop, as in the previous instal- 
lation, and the radio can be located at the antenna or 
elsewhere. An 802.3 connection will connect the radio 
to a wireless LAN access point. Each of the remote com- 

15 puter devices within the house will now have access to 
the wireless LAN 28. Ideally, the wireless LAN access 
point antenna 29 should be a directional antenna locat- 
ed high in the building pointing downward to provide 
coverage in the house while minimizing RF leakage out- 

20 side the house. Locating the antenna in the attic 
presents various problems from powering the device in 
the attic to cooling the LAN radios. Practically, it seems 
that a LAN antenna located anywhere in the house will 
be acceptable, as long as LAN access point antenna 

25 cable lengths are short. 

[0023] There may be a need to provide service to the 
roaming subscribers who choose to take their laptop 
computer away from their home service area to another 
service area. The laptop user will need to use a flat panel 

30 directional antenna which will be pointed toward the ac- 
cess points. The alignment of the access point will be 
critical to ensure service quality. As part of the laptop 
software, an alignment indicator will provide guidance 
in aligning the antenna. 

35 [0024] It is envisioned that the antenna will approxi- 
mately to 34 of an inch thick, with an aperture approx- 
imately the same size as the laptop (8*/> u x 1V). Some 
means of temporarily attaching the antenna panel to the 
back of the laptop, such as hook and loop fasteners, is 

40 convenient for transporting the antenna. Once the lap- 
top user arrives at the location where access is desired, 
the antenna can either be removed from the back of the 
laptop and oriented for best performance, or left at- 
tached to the laptop in very strong signal areas. The lap- 

45 top antenna may even be hinged to the laptop with a bi- 
axis alignment mechanism which changes the azimuth 
and elevation of the antenna. The antenna panels will 
support 45° dual slant polarization with conical beam 
shapes to eliminate any propagation effects which can 

50 affect signal quality. Furthermore, since the beam 
shapes are conical with dual polarization, standing the 
antenna on either side should not change signal quality. 
[0025] Wide-area wireless coverage is provided by 
base stations 36. The range of coverage provided by 

55 base stations 36 depends on factors like link budget, ca- 
pacity and coverage. Base stations are typically in- 
stalled in ceil sites by PCS (personal communication 
services) wireless service providers. Base stations mul- 
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tiplex end system traffic from their coverage area to the 
system's mobile switching center (MSC) 40 over wire 
line or microwave backhaul network 38. 
[0026] A wireless communication system with multi- 
sector directional antenna arrangements entitled "Multi- 
Sector Cell Pattern For A Wireless Communication Sys- 
tem", filed on December 26, 1997, by Walter Hon- 
charenko, can be used to provide the wireless coverage 
and is incorporated herein by reference. 
[0027] The invention is independent of the MAC and 
PHY (physical) layer of the air link and the type of mo- 
dem. The architecture is also independent of the phys- 
ical layer and topology of backhaul network 38. The only 
requirements for the backhaul network are that it must 
be capable of routing internet protocol (IP) packets be- 
tween base stations and the M SC wit h adeq uate per- 
formance. At Mobile Switching Center 40 (MSC 40), 
packet data inter-working function (IWF) 52 terminates 
the wireless protocols for this network. IP router 42 con- 
nects MSC 40 to public internet 44, private intranets 46 
or to internet service providers 46. Accounting and di- 
rectory servers 48 in MSC 40 store accounting data and 
directory information. Element management server 50 
manages the equipment which includes the base sta- 
tions, the IWFs and accounting/directory servers. 
[0028] The accounting server will collect accounting 
data on behalf of users and send the data to the service 
provider's billing system. The interface supported by the 
accounting server will send accounting information in 
American Management Association (AMA) billing 
record format or any other suitable billing format over a 
TCP/IP (transport control protocol/internet protocol) 
transport to the billing system (which is not shown in the 
figure). 

[0029] The network infrastructure provides PPP 
(point-to-point protocol) service to end systems. The 
network provides (1 ) fixed wireless access with roaming 
(log-in anywhere that the wireless coverage is available) 
to end systems and (2) low speed mobility and hand- 
offs. When an end system logs on to a network, in it may 
request either fixed service (i.e., stationary and not re- 
quiring handoff services) or mobile service (i.e., needing 
handoff services). An end system that does not specify 
fixed or mobile is regarded as specifying mobile service. 
The actual registration of the end system is the result of 
a negotiation with a home registration server based on 
requested level of service, the level of services sub- 
scribed to by the user of the end system and the facilities 
available in the network. 

[0030] If the end system negotiates a fixed service 
registration (i.e., not requiring handoff services) and the 
end system is located in the home network, an IWF (in- 
ter-working function) is implemented in the base station 
to relay traffic between the end user and a communica- 
tions server such as a PPP server (i.e., the point with 
which to be connected, for example, an ISP PPP server 
or a corporate intranet PPP server or a PPP server op- 
erated by the wireless service provider to provide cus- 



tomers with direct access to the public internet). It is an- 
ticipated that perhaps 80% of the message traffic will be 
of this category, and thus, this architecture distributes 
IWF processing into the base stations and avoids mes- 
5 sage traffic congestion in a central mobile switching 
center. 

[0031] If the end system requests mobile service 
(from a home network or a foreign network) or if the end 
system request roaming service (i.e., service from the 
10 ■ home network through a foreign network), two IWFs are 
established: a sorting IWF typically established in the 
base station of the network to which the end system is 
attached (be it the home network or a foreign network) 
and a home IWF typically established in mobile switch- 
es ing center MSC of the home network. Since this situation 
iS-anticipated.to.in-volve only about-20% of-the-message- 
traffic, the message traffic congestion around the mobile 
switching center is minimized. The serving IWF and the 
wireless hub may be co-located in the same nest of com- 
20 puters or may even be programmed in the same com- 
puter so that a tunnel using an XTunnel protocol need 
not be established between the wireless hub and the 
serving IWF. 

[0032] However, based on available facilities and the 

25 type and quality of service requested, a serving IWF in 
a foreign network may alternatively be chosen from fa- 
cilities in the foreign MSC. Generally, the home IWF be- 
comes an anchor point that is not changed during the 
communications session, while the serving IWF may 

30 change if the end system moves sufficiently. 

[0033] The base station includes an access hub and 
at least one access point (be it remote or collocated with 
the access hub). Typically, the access hub serves mul- 
tiple access points. While the end system may be at- 

35 tached to an access point by a wire or cable according 
to the teachings of this invention, in a preferred embod- 
iment the end system is attached to the access point by 
a wireless "air link ", in which case the access hub is 
conveniently referred to as a wireless hub. While the ac- 

40 cess hub is referred to as a "wireless hub " throughout 
the description herein, it will be appreciated that an end 
system coupled through an access point to an access 
hub by wire or cable is an equivalent implementation 
and is contemplated by the term "access hub". 

45 [0034] In the invention, an end system includes an 
end user registration agent (e.g., software running on a 
computer of the end system, its modem or both) that 
communicates with an access point, and through the ac- 
cess point to a wireless hub. The wireless hub includes 

50 a proxy registration agent (e.g., software running on a 
processor in the wireless hub) acting as a proxy for the 
end user registration agent. Similar concepts used in, 
for example, the IETF proposed Mobile IP standard are 
commonly referred to as a foreign agent (FA). For this 

55 reason, the proxy registration agent of the present in- 
vention will be referred to as a foreign agent, and as- 
pects of the foreign agent of the present invention that 
differ from the foreign agent of Mobile IP are as de- 
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scribed throughout this description. 
[0035] Using the proxy registration agent (i.e., foreign 
agent FA) in a base station, the user registration agent 
of an end system is able to discover a point of attach- 
ment to the network and register with a registration serv- 5 
er in the MSC (mobile switching center) of the home net- 
work. The home registration server determines the 
availability of each of the plural inter-working function 
modules (IWFs) in the network (actually software mod- 
ules that run on processors in both the MSC and the 
wireless hubs) and assigns I WF(s) to the registered end 
system. For each registered end system, a tunnel (using 
the XTunnel protocol) is created between the wireless 
hub in the base station and an inter-working friction 
(IWF) in the mobile switching center (MSC), this tunnel 
transporting PPP frames between the end system and 
the IWR 

[0036] As used herein, the XTunnel protocol is a pro- 
tocol that provides in-sequence transport of PPP data 
frames with flow control. This protocol may run over 
standard IP networks or over point-to-point networks or 
over switched network like ATM data networks or frame 
relay data networks. Such networks may be based on 
T1 or T3 links or based on radio links, whether land 
based or space based. The XTunnel protocol may be 
built by adapting algorithms from L2TP (layer 2 tun- 
neling protocol). In networks based on links where lost 
data packets may be encountered, a re -trans miss ion 
feature may be a desirable option. 
[0037] The end system's PPP peer (i.e., a communi- 
cations server) may reside in the IWF or in a corporate 
intranet or ISP's network. When the PPP peer resides 
in the IWF, an end system is provided with direct irternet 
access. When the PPP peer resides in an intranet or 
ISP, an end system is provided with intranet access or 
access to an ISP. In order to support intranet or ISP ac- 
cess, the IWF uses the layer two tunneling protocol 
(L2TP) to connect to the intranet or ISP's PPP server 
From the point of view of the intranet or ISP's PPP serv- 
er, the IWF looks like a network access server (NAS). 
PPP traffic between the end system and the IWF is re- 
layed by the foreign agent in the base station. 
[0038] In the reverse (up link) direction, PPP frames 
traveling from the end system to the IWF are sent over 
the MAC and air link to the base station. The base sta- 
tion relays these frames to the IWF in the MSC using 
the XTunnel protocol. The IWF delivers them to a PPP 
server for processing. For internet access, the PPP 
server may be in the same machine as the IWF. For ISP 
or intranet access, the PPP server is in a private network 
and the IWF uses the layer two tunneling protocol 
(L2TP) to correct to it. 

[0039] In the forward (down link) direction, PPP 
frames from the PPP server are relayed by the IWF to 
the base station using the XTunnel protocol. The base 
station de-tunnels down link frames and relays them 
over the air link to the end system, where they are proc- 
essed by the end system's PPP layer. 



[0040] To support mobility, support for hand-offs are 
included. The MAC layer assists the mobility manage- 
ment software in the base station and the end system 
to perform hind-offs efficiently. Hand-offs are handled 
transparently from the peer PPP entities and the L2TP 
tunnel. If an end system moves from one base station 
to another, a new XTunnelis created between the new 
base station and the original IWF. The old XTunneli rom 
the old base station will be deleted. PPP frames will 
transparently traverse the new path. 
[0041] The network supports roaming (i.e., when the 
end user connects to its home wireless service provider 
through a foreign wireless service provider). Using this 
feature, end systems are able to roam away from the 
home network to a foreign network and still get service, 
provided of course that the foreign wireless service pro- 
vider and the end system's home wireless service pro- 
vider have a service agreement. 

[0042] In FIG. 6, roaming end system 60 has traveled 
to a location at which foreign wireless service provider 
62 provides coverage. However, roaming end system 
60 has a subscriber relationship with home wireless 
service provider 70. In the present invention, home wire- 
less service provider 70 has a contractual relationship 
with foreign wireless service provider 62 to provide ac- 
cess services. Therefore, roaming end system 60 con- 
nects to base station 64 of foreign wireless service pro- 
vider 62 over the air link. Then, data is relayed from 
roaming end system 60 through base station 64, 
through serving IWF 66 of foreign wireless service pro- 
vider 62, to home IWF 72 of home wireless service pro- 
vider 70, or possibly through home IWF 72 of home wire- 
less service provider 70 to internet service provider 74. 
[0043] An inter-service provider interface, called the 
l-interface, is used for communications across wireless 
service provider (WSP) boundaries to support roaming. 
This interface is used for authenticating, registering and 
for transporting the end system's PPP frames between 
the foreign WSP and the home WSP. 
[0044] PPP frames in the up link and the down link 
directions travel trough the end system's home wireless 
service provider (WSP). Alternatively, PPP frames di- 
rectly transit from the foreign WSP to the destination net- 
work. The base station in the foreign WSP is the end 
system's point of attachment in the foreign network. This 
base station sends (and receives) PPP frames to (and 
from) a serving in the foreign WSP's mobile switching 
center. The serving IWF connects over the l-interface to 
the home IWF using a layer two tunnel to transport the 
end system's PPP frames in both directions. The serving 
IWF in the foreign WSP collects accounting data for au- 
diting. The home IWF in the home WSP collects ac- 
counting data for billing. 

[0045] The serving IWF in the foreign WSP may be 
combined with the base station in the same system, thus 
eliminating the need for the X -Tunnel. 
[0046] During the registration phase, a registration- 
server in the foreign WSP determines the identity of the 
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roaming end system's home network. Using this infor- 
mation, the foreign registration server communicates 
with the home registration server to authenticate and 
register the end system. These registration messages 
flow over the l-interface. Once the end system has been 
authenticated and registered, a layer two tunnel is cre- 
ated between the base station and the serving IWF us- 
ing the XTUNNEL protocol and another layer two tunnel 
is created between the serving IWF and the home IWF 
over the l-X Tunnel. The home IWF connects to the end 
system's PPP peer as before, using L2TP (layer 2 tun- 
neling protocol). During hand-offs, the location of the 
home IWF and the L2TP tunnel remains fixed. As the 
end system moves from one base station to another 
base station, a new tunnel is created between the new 
-base station and-the serving -iW-F-and-the old tunnel be- - 
tween the old base station and the serving IWF is delet- 
ed. If the end system moves far enough, so that a new 
serving IWF is needed, a new l-X tunnel will be created 
between the new serving IWF and the home IWF. The 
old tunnel between the old serving and the home will be 
deleted. 

[0047] To support foaming, the l-interface supports 
authentication, registration and data transport services 
across wireless service provider boundaries. Authenti- 
cation and registration services are supported using the 
IETF Radius protocol. Data transport services to trans- 
fer PPP frames over a layer two tunnel are supported 
using the l-XTunnef protocol. This protocol is based on 
the IETF L2TP protocol. 

[0048] As used in this description, the term home t WF 
refers to the IWF in the end system's home network. The 
term serving IWF refers to the IWF in the foreign network 
which is temporarily providing service to the end system. 
Similarly, the term home registration server refers to the 
registration server in the end system's home network 
and the term foreign registration server refers to the reg- 
istration server in the foreign network through which the 
end system registers while it is roaming. 
[0049] The network supports both fixed and dynamic 
IP address assignment for end systems. There are two 
types of IF addresses that need to be considered. The 
first is the identity of the end system in its home network. 
This may be a structured user name in the format us- 
er@domain. This is different from the home IP address 
used in mobile IP. The second address is the IP address 
assigned to the end system via the PPP IPC address 
protocol. The domain sub-field of the home address is 
used to identify the user's home domain and is a fully 
qualified domain name. The user sub-field of the hime 
address is used to identify the user in the home domain. 
The User-Name is stored on the end system and in the 
subscriber data-base at the MSC and is assigned to the 
user when he or she subscribes to the service. The do- 
main sub-field of the User-Name is used during roaming 
to identify roaming relationships and the home registra- 
tion'server for purposes of registration and authentica- 
tion. Instead of the structured user name, another 



unique identifier may be used to identify the user's home 
network and the user's identity in the home network. 
This identifier is sent in the registration request by the 
end system. 

s [0050] The PPP IPCP is used to negotiate the IP ad- 
dress for the end system. Using IP configuration proto- 
col IPCP, the end system is able to negotiate a fixed or 
dynamic IP address. 

[0051] Although the use of the structured user-name 
10 field and the non-use of an IP home address is a feature 
that characterizes the present invention over a known 
mobile I P, the network may be enhanced to also support 
end systems that have no user-name and only a non- 
null home IP address, if mobile IP and its use in con- 
15 junction with PPP end systems becomes popular. The 
„ — ppp^server may be^configured-by-the^service-provider- 



30 



35 



to assign IP addresses during the IPCP address assign- 
ment phase that are the same as the end system's home 
IP address. In this case, the home address and the IPCP 

20 assigned IP address will be identical. 

[0052] In FIG. 7, base station 64 and air links from end 
systems form wireless sub-network 80 that includes the 
air links for end user access, at least one base station 
(e.g., station 64) and at least one backhaul network (e. 

25 g . t 38 of FIG. 2) from the base station to MSC 40 (FIG. 
2). The wireless sub-network architecture of, for exam- 
ple, a 3-sectored base station includes the following log- 
ical functions. 
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1 . Access point function. Access points 82 perform 
MAC layer bridging and MAC layer association and 
dissociation procedures. An access point includes 
a processor (preferably in the form of custom appli- 
cation specific integrated circuit ASIC), a link to a 
wireless hub (preferably in the form of an Ethernet 
link on a card or built into the ASIC), a link to an 
antenna (preferably in the form of a card with a data 
modulator/demodulator and a transmitter/receiver), 
and the antenna to which the end system is cou- 
pled. The processor runs software to perform a data 
bridging function and various other functions in sup- 
port of registration and mobility handovers as fur- 
ther described herein. See discussion with respect 
to FIGS. 10, 11 and 14. 

Access points (APs) take MAC layer frames 
from the air link and relay them to a wireless hub 
and vice versa. The MAC layer association and dis- 
association procedures are used by APs to main- 
tain a list of end system MAC addresses in their 
MAC address filter table. An AP will only perform 
MAC layer bridging on behalf of end systems whose 
MAC addresses are present in the table. An access 
point and its associated wireless hub are typically 
co-located. In its simplest form, an access point is 
just a port into a wireless hub. When the APs and 
the wireless hub are co-located in the same cell site, 
they may be connected together via a IEEE 802.3 
link. Sometimes, access points are located remote- 
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ly from the wireless hub and connected via a long 
distance link like a wired T1 trunk or even a wireless 
trunk. For multi-sector cells, multiple access points 
(i.e., one per sector) are used. 

5 

2. Wireless hub function. Wireless hub 84 performs 
the foreign agent (FA) procedures, backhaul load 
balancing (e.g., over multiple TVs), backhaul net- 
work interlacing, and the xtunnel procedures. When 
support for quality of service (QOS) is present, the io 
wireless hub implements the support for QOS by 
running the xtunnel protocol over backhauls with 
different QOS attributes. In a multi-sector cell site, 
a single wireless hub function is typically shared by 
multiple access points. is 

A wireless hub includes a processor, a link to 
one or more access points preferably in the form of 
an Ethernet link on a card or built into an ASIC), and 
a link to a backhaul line. The backhaul line is typi- 
cally a T1 or T3 communications line that terminates 20 
in the mobile switching center of the wireless serv- 
ice provider. The link to the backhaul line formats 
data into a preferred format, for example, an Ether- 
net format, a frame relay formal or an ATM format. 
The wireless hub processor runs software to sup- 25 
port data bridging and various other functions as de- 
scribed herein. See discussion with respect to 
FIGS. 12, 13 and 14. 

[0053] The base station design supports the following 30 
types of cell architectures. 

1 . Local AP architecture. In a local AP architecture, 
access points have a large (> = 2km, typically) 
range. They are co-located in the cell site with the 35 
wireless hub (FiG. 4). Access points may be con- 
nected to the wireless hub using an IEEE 802.3 net- 
work or may be directly plugged into the wireless 
hub's backplane or connected to the wireless hub 
using some other mechanism (e.g. universal serial 40 
bus, printer port, infra-red, etc.). It will be assumed 
that the first alternative is used for the rest of this 
discussion. The cell site may be omni or sectored 

by adding multiple access points and sectored an- 
tennas to a wireless hub. 45 

2. Remote AP architecture. In a remote AP archi- 
tecture, access points usually have a very small 
range, typically around 1 km radius. They are locat- 
ed remotely (either indoors or outdoors) from the so 
wireless hub. A T1 or a wireless trunk preferably 
links remote access points to the cell site where the 
wireless hub is located. From the cell site, a wire 
line backhaul or a microwave link is typically used 

to connect to the I WF in the MSC. If wireless trunk- 55 
ing between the remote AP and the wireless hub is 
used, omni or sectored wireless radios for trunking 
are utilized. The devices for trunking to remote ac- 



cess points are preferably co-located with the wire- 
less hub and may be connected to it using an IEEE 
802.3 network or may be directly plugged into the 
wireless hub's backplane. These devices will be re- 
ferred to by the term trunk AP. 

3. Mixed AP architecture. In a mixed architecture, 
the wireless sub-network will have to support re- 
mote and local access points. Remote access 
points may be added for hole filling and other ca- 
pacity reasons. As described earlier, T1 or wireless 
trunks may be used to connect the remote AP to the 
wireless hub. 

[0054] FIGS. 37 and 38 are system configuration di- 
agrams which illustrate possible connections. For case 
(i), the IWF1 is the anchor IWF and acts as the home 
agent, while the WH1 acts as the foreign agent. An Xtun- 
nel is used between the WH1 and IWF1 and a layer 2 
Tunneling protocol (L2TP) tunnel is used between the 
I WF1 and the PPP server. For case (ii), the WH and the 
serving IWF are colocated. The IWF1 is the anchor IWF 
and the serving IWF, IWF2 acts as the Foreign agent. 
An l-X tunnel is used between IWF and IWF2 and a 
L2TP tunnel is used between IWF1 and the PPP server. 
For case (iii), the serving IWF is IWF3 and the anchor 
IWF is IWF1. An Xtunnef is used between WH3 and 
IWF3, an l-Xtunnel is used between IWF3 and IWF1, 
and a L2TP tunnel is used between IWF1 and the PPP 
server. 

[0055] FIG. 38 illustrates the addition of a wireless 
hop (trunk AP) wherein the trunk AP may be colocated 
with WH. For this case, apart from all three possibilities 
described above, the following possibilities may also oc- 
cur. For case (i), the Trunk AP1 is the foreign agent and 
IWF1 is the anchor IWF. An Xtunnel is used between 
the Trunk AP1 and the anchor IWF, and a L2TP tunnel 
is used between the anchor IWF and the PPP server. 
For case (ii), the serving IWF2 is the foreign agent. An 
Xtunnel is used between the trunk AP2 and the IWF2, 
an l-Xtunnel is used between the IWF2 and the anchor 
IWF1 and a L2TP tunnel is used between the anchor 
IWF and the PPP server. For case (iii), the serving IWF 
is the foreign agent. An Xtunnel is used between the 
trunk AP3 and the IWF3, an l-Xtunnel is used between 
IWF3 and anchor IWF1 and a L2TP tunnel is used be- 
tween the anchor IWF1 and the PPP server. 
[0056] FIGS. 39-42 illustrate several handoff scenar- 
ios as well as various connections between the ele- 
ments of the systems. 

[0057] FIG. 8 shows a cell with three sectors using 
local APs only. The access points and the wireless hub 
are co-located in the base station and are connected to 
each other with 802.3 links. 

[0058] FIG. 9 shows an architecture with remote ac- 
cess points 82 connected to wireless hub 84 using wire- 
less trunks 86. Each trunk access point in the base sta- 
tion provides a point to multi-point wireless radio link to 
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the remote micro access points (R-AP in figure). The 
remote access points provide air link service to end sys- 
tems. The wireless hub and the trunk access points are 
co-located in the base station and connected together 
via 802.3 links. This figure also shows remote access 
points 82R connected to the wireless hub via point to 
point T1 links. In this scenario, no trunk APs are re- 
quired. 

[0059] To support all of the above cell architectures 
and the different types of access points that each cell 
might use, the network architecture follows the following 
rules: 

1 . Access points function as MAC layer bridges. Re- 
mote access points perform MAC bridging between 

— —the-air-link-to-the-end-systems-and-the-wiFeless-or- 
T1 trunk to the cell site. Local access points perform 
MAC bridging between the air link to the end sys- 
tems and the wireless hub. 

2. Trunk access points also function as MAC layer 
bridges. They perform MAC bridging between the 
trunk (which goes to the access points) and the 
wireless hub. 

3. The wireless flub is connected to all co-located 
MAC bridges (i.e. local access points or trunk ac- 
cess points) using a 802.3 link initially. 
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whose MAC addresses are not present in the table. 
The APs always forward MAC broadcast frames 
and MAC frames associated with end system reg- 
istration functions regardless of the contents of the 
MAC address filter table. 

5. Local access points use ARP to resolve MAC ad- 
dresses for routing IP traffic to the wireless hub. 
Conversely, the wireless hub also uses ARP to 
route IP packets to access points. U DP/IP is used 
for network management of access points. 

6. Remote access points connected via T1 do not 
use ARP since the link will be a point to point link. 



___7_ Support-for-hand-offs-is-done-with-assistanee- 
from the MAC layer. 

[0061] In a cell architecture using wireless trunks and 
trunk APs, the following rules are followed. 

1 . Trunk access points are co-located with the wire- 
less hub and connected to it using point to point 
802.3 links or other suitable means. 

2. Wireless trunk sectorization is supported by add- 
ing trunk access points with sectored antennas to 
the cell site. 



[0060] Additionally, where local access points or re- 30 
mote access points with T1 trunks are used, the follow- 
ing rules are followed. 

1 . Local access points are co-located with the wire- 
less hub and connected to it using point to point 35 
802.3 links or a shared 802.3 network. Remote ac- 
cess points are connected to the wireless hub using 
point to point T1 trunks. 

2. Sectorization is supported by adding access 40 
points with sectored antennas to the cell site. 

3. For each access point connected to the wireless 
hub, there is a foreign agent executing in the wire- 
less hub which participates in end system registra- <*s 
tion. MAC layer association procedures are used to 
keep the MAC address filter tables of the access 
points up to date and to perform MAC layer bridging 
efficiently. The wireless hub participates in MAC as- 
sociation functions so that only valid MAC address- so 
es are added to the MAC address filter tables of the 
access points. 

4. The wireless hub relays frames from the access 
points to the MSC IWF and vice versa using the 55 
xtunnel protocol unless the IWF is co- located with 

the wireless hub. The MAC address filter table is 
used to filter out those unicast MAC data frames 



3. Hand-offs across backhaul sectors are done us- 
ing the foreign agent in the wireless hub. For each 
backhaul sector, there is a foreign agent executing 
in the wireless hub. 

4. The trunk APs do not need to participate in MAC 
layer end system association and hand off proce- 
dures. Their MAC address filter tables will be dy- 
namically programmed by the wireless hub as end 
systems register with the network. The MAC ad- 
dress filter table is used to filter out unicast MAC 
frames. Broadcast MAC frames or MAC frames 
containing registration packets are allowed to al- 
ways pass through. 

5. Trunk APs use ARP to resolve MAC addresses 
for routing I P traffic to the wireless hub. Conversely, 
the wireless hub use ARP to route IP packets to 
trunk APs. UDP/IP is used for network management 
of trunk APs. 

6. In a single wireless trunk sector, MAC association 
and hand-offs from one access point to another is 
done using the MAC layer with the assistance of the 
foreign agent in the wireless hub. Using these MAC 
layer procedures, end systems associate with ac- 
cess points. As end systems move from one access 
point to another access point, the access points will 
use a MAC band off protocol to update their MAC 
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address filter tables. The wireless hub at the cell site 
provides assistance to access points to perform this 
function. This assistance includes relaying MAC 
layer hand off messages (since access points will 
not be able to communicate directly over the MAC 
layer with each other) and authenticating the end 
system for MAC layer registration and hand off and 
for updating the MAC address filter tables of the ac- 
cess points. 

7. The foreign agent for a wireless trunk sector is 
responsible for relaying frames from its trunk AP to 
the MSC and vice versa using the xtunnei protocol. 
Thus, the foreign agent for a trunk AP does not care 
about the location of the end system with respect to 
access points within that wireless trunk sector. In 
the down link direction, it just forwards frames from 
the mobile IP tunnel to the appropriate trunk AP 
which uses MAC layer bridging to send the frames 
to all the remote access points attached in that 
backhaul sector The access points consult their 
MAC address filter tables and either forward the 
MAC frames over the access network or drop the 
MAC frames. As described above, the MAC ad- 
dress filter tables are kept up to date using MAC 
layer association and hand off procedures. In the 
up link direction, MAC frames are forwarded by the 
access points to the backhaul bridge which for- 
wards item to the foreign agent in the wireless hub 
using the 302.3 link. 

8. ARP is nor be used for sending or receiving IP 
packets to the remote access points. The trunk ac- 
cess points determines the MAC address of the 
wireless hub using BOOTP procedures. Converse- 
ly, the wireless hub is configured with the MAC ad- 
dress of remote access points. U DP/IP is used for 
network management of access points and for end 
system association and hand off messages. 

[0062] IEEE 802.3 links in the cell site may be re- 
placed by higher speed links. 

[0063] FIG. 10 shows the protocol stack for a local ac- 
cess point. At the base of the stack is physical layer PHY 
Physical layer PHY carries data to and from an end sys- 
tem over the air using radio waves as an example. When 
received from an end system, the AP receives data from 
the physical layer and unpacks it from the MAC frames 
(the MAC layer). The end system data frames are then 
repacked into an Ethernet physical layer format (IEEE 
802.3 format) where it is sent via the Ethernet link to the 
wireless hub. When the AP's processor receives data 
from the wireless hub via its Ethernet link (i.e., the phys- 
ical layer), the data to be transmitted to an end system, 
the AP packs the data in a medium access control 
(MAC) format, and sends the MAC layer data to its mod- 
ulator to be transmitted to the end system using the PHY 
layer. 



[0064] In FIG. 11, the MAC and PHY layers to/from 
the end system of FIG. 10 are replaced by a MAC and 
PHY for the trunk to the cell site for a remote access 
point. Specifically, for a T1 trunk, the high level data link 
5 control protocol (HDLC protocol) is preferably used over 
the T1. 

[0065] FIG. 1 2 depicts the protocol stack for the wire- 
less hub that bridges the backbaul line and the trunk to 
the remote access point. The trunk to the remote APs 

to are only required to support remote access points (as 
distinct from Ethernet coupled access points). The MAC 
and PHY layers for the wireless trunk to the remote APs 
provide a point to multipoint link so that one trunk may 
be used to communicate with many remote APs in the 

15 same sector. 

[0066] The wireless hub bridges the trunk to the re- 
mote APs and the backhaul line (e.g. : Tl or T3) to the 
network's mobile switching center (MSC). The protocol 
stack in the wireless hub implements MAC and PHY lay- 

20 ers to the MSC on top of which is implemented an IP 
layer (Internet Protocol) on top of which is implemented 
a UDP layer (Universal Datagram Protocal, in combina- 
tion referred to as UDP/IP) for network management on 
top of which is implemented an XTunnel protocol. The 

25 XTunnel protocol is a new format that includes aspects 
of mobility (e.g. as in mobile IP) and aspects of the Layer 
2 Tunnel Protocol (L2TP). The XTunnel protocol is used 
to communicate from the wireless hub to the MSC and 
between inter-working functions (IWFs) in different net- 

30 works or the same network. 

[0067] In FIG. 13, the protocol stack for the relay func- 
tion in the base station for supporting remote access 
points is shown. The relay function includes an interface 
to the backhaul line (depicted as the wireless hub) and 

35 an interface to the remote AP (depicted as a trunk AP). 
From the point of view of the wireless hub, the trunk AP 
(depicted in FIG.1 3) actually behaves like the AP depict- 
ed in FIG. 10. Preferably, the base station protocol 
stacks are split up into a wireless hub and a trunk AP 

40 with an Ethernet in between. In an N-sector wireless 
trunk, there are N wireless trunk APs in the cell site and 
one wireless hub. 

[0068] In FIG. 14, the base station protocol stack for 
a cell architecture using a local AP is shown. The relay 

45 function includes an interface to the backhaul line (de- 
picted as the wireless hub) and an air link interface to 
the end system (depicted as an AP). From the point of 
view of the wireless hub, the AP (depicted in FIGS. 11 
and 14) actually behaves like the trunk AP depicted in 

50 FIG. 1 1 . Preferably, the base station protocol stacks are 
split up into a wireless hub and a trunk AP with an Ether- 
net in between. In a N-sector cell, there are N access 
points and a single wireless hub. 

[0069] The backhaul network from the base station to 
55 the MSC has the following attributes. 

1. The network is capable of routing IP datagrams 
between the base station and the MSC. 
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2. The network is secure. It is not a public internet. 
Traffic from trusted nodes only are allowed onto the 
network since the network will be used for not only 
transporting end system traffic, but also for trans- 
porting, authentication, accounting, registration and 
management traffic. 

3. The network has the necessary performance 
characteristics. 

4. Base stations support IP over Ethernet links. 

In typical application, the service provider is responsible 
for installing and maintaining the backhaul network on 
which the equipment is installed. 

[0070] —The base stations supports the-foilowing-back- 
haul interfaces for communicating with the MSC. 

1. Base stations support IP over PPP with HDLC 
links using point to point T1 or fractional T3 links. 

2. Base stations support IP over frame relay using 
T1 or fractional T3 links. 

3. Base stations support IP over AAL5/ATM using 
T1 or fractional T3 links. 

[0071] Since all of the above interfaces are based on 
IETF standard encapsulations, commercial routers may 
be used in the MSC to terminate the physical links of the 
backhaul network. Higher layers are passed on and 
processed by the various servers and other processors. 
[0072] End system registration procedures above the 
MAC layer are supported. In the following, end system 
registration procedures at the MAC layer are ignored ex- 
cept where they impact the layers above. 
[0073] End systems may register for service on their 
home network or from a foreign network. In both sce- 
narios, the end system uses a foreign agent (FA) in the 
base station to discover a point of attachment to the net- 
work and to register. In the former case, the FA is in the 
end system's home network. In the latter case, the FA 
is in a foreign network, in either case, the network uses 
an I WF in the end system's home network as an anchor 
point (i.e., unchanging throughout the session in spite 
of mobility). PPP frames to and from the end system 
travel via the FA in the base station to the IWF in the 
home network. If the end system is at home, the home 
IWF is directly convected by means of the xtunnel pro- 
tocol to the base station. Note that the home IWF may 
be combined with the base station in the same mode. If 
the end system is roaming, a serving IWF in the foreign 
network is connected to the home IWF over an [-inter- 
face. The serving IWF relays frames between the base 
station and the home IWF. Note that the serving IWF 
may also be combined with the base station in the same 
mode. From the home IWF, data is sent to a PPP server 
which may reside in the same IWF or to a separate serv- 
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er using the L2TP protocol. The separate server may be 
owned and operated by a private network operator (e. 
g. ISP or corporate intranet) who is different from the 
wireless service provider. For the duration of the ses- 

$ sion, the location of the home IWF and the PPP server 
remains fixed. If the end system moves while connect- 
ed, it will have to re-register with a new foreign agent. 
However, the same home IWF and PPP server contin- 
ues to be used. A new xtunnel is created between the 

10 new FA and the IWF and the old xtunnel between the 
old foreign agent and the IWF is destroyed. 
[0074] FIG. 15 shows this network configuration for 
two end systems A and B, both of whose home wireless 
network is wireless service provider A (WSP-A). One 

15 end system is registered from the home wireless net- 

— work and4heother4rom a-foreign-wireless network. The 
home IWF in WSP-A serves as the anchor point for both 
end systems. For both end systems, data is relayed to 
the home IWF. The home IWF connects to an internet 

20 service provider's PPP server owned by ISP-A. Here it 
is assumed that both end systems have subscribed to 
the same ISP. If that were not the case, then the home 
IWF would be shown also connected to another ISP. 
[0075] Within a wireless service providers network, 

25 data between base stations and the IWF is carried using 
the xrunne/protocol. Data between the IWF and the PPP 
server is carried using Layer 2 Tunneling Protocol 
(L2TP). Data between the serving IWF and the home 
IWF is carried using the I -xtunnel protocol. 

30 [0076] In a simple scenerio, for a user in their home 
network requiring fixed service, the home IWF function 
may be dynamically actuated in the base station. Also, 
the serving IWF function may be activated for a roaming 
user in the base station. 

35 [0077] Always using an IWF in the home network has 
its advantages and disadvantages. An obvious advan- 
tage is simplicity. A disadvantage is that of always hav- 
ing to relay data to and from a possibly remote home 
IWF. The alternative is to send all the necessary infor- 

40 mation to the serving IWF so that it may connect to the 
end system's ISP/intranet and for the serving IWF to 
send accounting information in near real time back to 
the accounting server in the home network. This func- 
tionality is more complex to implement, but more effi- 

^5 cient because it reduces the need to relay data over po- 
tentially long distances from the foreign network to the 
home network. 

[0078] For example, consider a case of a user who 
roams from Chicago to Hong Kong. If the user's home 

50 network is in Chicago and the user registers using a 
wireless service provider in Hong Kong, then in the first 
configuration, the anchor point will be the home IWF in 
Chicago and all data will have to be relayed from Hong 
Kong to Chicago and vice versa. The home IWF in Chi- 

55 cago will connect to the user's ISP in Chicago. With the 
second configuration, the end system user will be as- 
signed an ISP in Hong Kong. Thus, data will not always 
have to be relayed back and forth between Chicago and 
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Hong Kong. In the second configuration, the serving 
IWF will serve as the anchor and never change for the 
duration of the session even if the end system moves. 
However, the location of the FA may change as a result 
of end system movement in Hong Kong. 
[0079] FIG. 16 shows the second network configura- 
tion. In this figure, the home network for end system A 
and B is WSP-A. End system A registers from its home 
network, using its home IWF as an anchor point, and 
also connects to its ISP-A using the ISPs PPP server. 
End system B registers from the foreign network of 
WSP-B and uses a serving IWF which serves as the an- 
chor point and connects the end system to an ISP using 
the ISP's PPP server. In this configuration, data for end 
system B does not have to be relayed from the foreign 
network to the home network and vice versa. 
[0080] In order for this configuration to work, not only 
must there be roaming agreements between the home 
and the foreign wireless service providers, but there also 
must be agreements between the foreign wireless serv- 
ice provider and the end system's internet service pro- 
vider directly or through an intermediary. In the example 
above, not only must the wireless service provider in 
Hong Kong have a business agreement with the wire- 
less service provider in Chicago., but the WSP in Hong 
Kong must have a business agreement with the user's 
Chicago ISP and access to the Chicago ISPs PPP serv- 
er in Hong Kong or a business agreement with another 
ISP locally in Hong Kong who has a business agreement 
for roaming with the user's Chicago ISP. Additionally, the 
WSP in Hong Kong must be able to discover these 
roaming relationships dynamically in order to do user 
authentication and accounting and to set up the appro- 
priate tunnels. 

[0081] It is difficult for those companies who are in the 
Internet infrastructure business to work out suitable 
standards in the IETF for all of these scenarios. Thus, 
a preferable embodiment for the present invention is to 
implement the simpler, potentially less efficient configu- 
ration, where the IWF in the home network is always 
used as the anchor point. However, in the presence of 
suitable industry standardization of protocols for Inter- 
net roaming, the second coufigurafion should be regard- 
ed as equivalent or alternative embodiment. 
[0082] An end system will have to register with the 
wireless network before it can start PPP and send and 
receive data. The end system first goes through the FA 
discovery and registration phases. These phases au- 
thenticate and register the end system to the wireless 
service provider. Once these phases are over, the end 
system starts PPP. This includes the PPP link establish- 
ment phase, the PPP authentication phase and the PPP 
network control protocol phase. Once these phases are 
over, the end system is able to send and receive I P pack- 
ets using PPP 

[0083] The following discussion assumes that the end 
system is roaming and registering from a foreign net- 
work. During the FA discovery phase, the end system 



(through its user registration agent) waits for or solicits 
an advertisement from the foreign agent. The user reg- 
istration agent uses advertisement messages sent by a 
near by foreign agent to discover the identity of the FA 
$ and to register. During this phase, the user registration 
agent of the end system selects a FA and issues a reg- 
istration request to it. The FA acting as a proxy registra- 
tion agent forwards the registration request to its regis- 
tration server (the registration server in the foreign 
10 WSP). The registration server uses User-Name from the- 
user registration agent's request to determine the end 
system's home network, and forwards the registration 
request for authentication to a registration server in the 
home network. Upon receiving the registration request 
15 relayed by the foreign registration server, the home reg- 
istration server authenticates the identity of the foreign 
registration server and also authenticates the identity of 
the end system. If authentication and registration suc- 
ceeds, the home registration server selects an IWF in 
20 the home network to create an l-xtunnel link between 
the home IWF and the serving IWF (in the foreign WSP). 
The IWF in the home network serves as the anchor point 
for the duration of the PPP session. 
[0084] Once the authentication and registration phas- 
es es are over, the various PPP phases will be started. At 
the start of PPP, an L2TP connection is created between 
the home IWF and requested ISP/intranet PPP server. 
In the PPP authentication phase, PPP passwords using 
PAP or CHAP are exchanged and the ISP or intranet 
so ppp server independently authenticates the identity of 
the end system. 

[0085] Once this succeeds, the PPP network control 
phase is stated. In this phase, an IP address is negoti- 
ated and assigned to the end system by the PPP server 
35 and the use of TCP/IP header compression is also ne- 
gotiated. When this is complete, the end system is able 
to send and receive IP packets using PPP to its ISP or 
a corporate intranet. 

[0086] Note that two levels of authentication are per- 

40 formed. The authentication authenticates the identity of 
the end system to the registration server in the home 
network and the identities of the foreign network and the 
home network to each other. To perform this function, 
the foreign agent forwards the end system's registration 

45 request using, for example, an IETF Radius protocol to 
a registration server in its local MSC in a Radius Access- 
Request packet. Using the end system's domain name, 
the foreign registration server determines the identity of 
the end system's home network and home registration 

50 server, and acting as a Radius proxy, encapsulates and 
forwards the request to the end system's home registra- 
tion server. If the foreign registration server cannot de- 
termine the identity of the end system's home, it may 
optionally forward the Radius request to a registration 

55 server that acts like a broker (e.g. one that is owned by 
a consortium of wireless service providers), which can 
in turn proxy the Radius Access -Request to the final 
home registration server If the local registration server 
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is unable to service the registration request locally or by 
proxying, then it rejects the foreign agent's registration 
request and the foreign agent rejects the end system's 
registration request. Upon receiving the Radius Access- 
Request, the home registration server performs the nec- s 
essary authentication of the identifies of the foreign net- 
work and the end system. If authentication and registra- 
tion succeeds, the home registration server responds 
with a Radius Access-Response packet to the foreign 
registration server which sends a response to the for- to 
eign agent so that a round trip can be completed. The 
registration request is rejected if the home registration 
server is unable to comply for any reason. 
[0087] The second level of authentication verifies the 
identity of the end system to the intranet or ISP PPP ?s 
_s.e.rv.e.r._PRE authentication^separateJrom^mobility^aur^ _ 
thentication allows the infrastructure equipment to be 
deployed and owned separately from the ISP. 
[0088] FIG. 17 is a ladder diagram showing the reg- 
istration sequence for a roaming end system. It is as- 20 
sunned that the PPP server and the home I WF are in the 
same server and L2TP is not required. Note the inter- 
actions with accounting servers to start accounting on 
behalf of the registering end system and also directory 
servers to determine the identity of the home registration 2S 
server and to authenticate the end system's identity. 
More information on accounting, billing, roaming (be- 
tween service providers) and settlement will be provided 
below. 

[0089] MAC layer messages from the user registra- 30 
tion agent of the end system may be used to initiate 
Agent Solicitation. The MAC layer messages are not 
shown for clarity. 

[0090] In FIG. 17, the end system (mobile) initially so- 
licits an advertisement and the foreign agent replies with 35 
an advertisement that provides the end system with in- 
formation about the network to which the foreign agent 
belongs including a care of address of the foreign agent. 
Alternatively, this phase may be removed and all net- 
work advertisements may be done by a continuously 40 
emitted MAC layer beacon message. In this case, the 
network is assumed to be a foreign wireless service pro- 
vider. Then, a user registration agent (in the end system) 
incorporates the information about the foreign agent (in- 
cluding the user name and other security credentials) 45 
and its network into a request and sends the request to 
the foreign agent. The foreign agent, as a proxy regis- 
tration agent, relays the request to the foreign registra- 
tion server (i.e., the registration server for the foreign 
wireless service provider. Then, the foreign registration so 
server, recognizing that it is not the home directory, ac- 
cesses the foreign directory server with the FDD in the 
foreign wireless service provider to learn how to direct 
the registration request to the home registration server 
of the wireless service provider to which the end system 55 
belongs. The foreign registration server responds with 
the necessary forwarding information. Then, the foreign 
registration server encapsulates the end system's reg- 



istration request in a Radius access request and relays 
the encapsulated request to the home registration serv- 
er of the wireless service provider to which the end sys- 
tem belongs. The home registration server accesses the 
home directory server with the HDD of the home regis- 
tration serverto learn at least authentication information 
about the foreign service provider. Optionally, the home 
registration server accesses the subscriber's directory 
to learn detail subscriber service profile information (e. 
g., quality of service options subscribed to, etc.). When 
all parties are authenticated, the home registration serv- 
er sends a start IWF request to the home I WF and PPP 
server. The home IWF and PPP server starts the home 
accounting server and then sends a start IWF response 
to the home registration server. The home registration 
serve r4hen-sends a Radius access response to the for- 
eign registration server. The foreign registration server 
then sends a start IWF request to the serving IWF serv- 
er. The serving IWF server starts the serving accounting 
server and then sends a start IWF response to the for- 
eign registration server. The foreign registration server 
sends a registration reply to the foreign agent, and the 
foreign agent relays the registration reply to the end sys- 
tem. 

[0091] A link control protocol (LCP) configuration re- 
quest is send by the end system through the foreign reg- 
istration server to the home IWF and PPP server. The 
home IWF and PPP server sends an LCP configuration 
acknowledgment through the foreign registration server 
to the end system. 

[0092] Similarly, a password authentication protocol 
(PAP) authentication request is sent to and acknowl- 
edged by the home IWF and PPP server. Alternatively, 
a challenge authentication protocol (CHAP) may be 
used to authenticate. Both protocols may be used to au- 
thenticate or this phase may be skipped. 
[0093] Similarly, an IP configuration protocol (IPCP) 
configure request is sent to and acknowledged by the 
home IWF and PPP server. 

[0094] The connection to the end system may be ter- 
minated because of any one of the following reasons. 

1. User initiated termination. Underthis scenario, the 
end system first terminates the PPP gracefully. This 
includes terminating the PPP network control pro- 
tocol (IPCP) followed by terminating the PPP link 
protocol. Once this is done, the end system de-reg- 
isters from the network followed by termination of 
the radio link to the access point. 

2. Loss of wire/ess link. This scenario is detected 
by the modem and reported to the modem driver in 
the end system. The upper layers of the software 
are notified to terminate the stacks and notify the 
user. 

3. Loss of connection to the foreign agent. This sce- 
nario is detected by the mobility driver in the end 
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system. After trying to re-establish contact with a 
(potentially new) foreign agent and failing, the driver 
sends an appropriate notification up the protocol 
stack and also signals the modem hardware below 
to terminate the .wireless link. 5 

4. Loss of connection to the IWF. This is substan- 
tially the same as for loss of connection to the for- 
eign agent. 

10 

5. Termination of PPP by IWF or PPP server This 
scenario is detected by the PPP software in the end 
system. The end system's PPP driver is notified of 
this event. It initiates de-registration from the net- 
work followed by termination of the wireless link to is 
the access point. 

[0095] End system service configuration refers to the 
concept of configuring the network service for an end 
system based on the subscriber's service profile. The 20 
subscriber's service profile is stored in a subscriber di- 
rectory. The service profile contains information to ena- 
ble the software to customize wireless data service on 
behalf of the subscriber. This includes information to au- 
thenticate the end system, allow the end system to roam 25 
and set up connections to the end system's internet 
service provider. Preferably, this information also in- 
cludes other parameters, like, quality of service. In ad- 
dition to the subscriber directory, a home domain direc- 
tory (HDD) and a foreign domain directory (FDD) are 30 
used for roaming and for authenticating the foreign and 
home registration servers to each other. The HDD 
stores information about the end system's home net- 
work and the FDD stores information about foreign net- 
works that a subscriber may visit. 35 
[0096] FIG. 18 shows how these directories map into 
the network architecture and are used during registra- 
tion for an end system that is registering at home. In step 
0 the end system (mobile) solicits and receives an ad- 
vertisement from the foreign agent to provides the end 40 
system with information about the network to which the 
foreign agent belongs. In this case, the network is the 
home wireless service provider. In step 1 , user registra- 
tion agent (in the end system) incorporates the informa- 
tion about the foreign agent and its network and its se- 45 
curity credentials into a request and sends the request 
to the foreign agent. In step 2, the foreign agent, as a 
proxy registration agent, relays the request to the home 
registration server In step 3, the home registration serv- 
er accesses the HDD of the home wireless service pro- so 
viderto learn at least authentication information. In step 
4, the home registration server accesses the subscriber 
directory to learn detail subscriber service profile infor- 
mation (e.g., quality of service options subscribed to, 
etc.). In step 5, the home registration server notifies the ss 
foreign agent of the access response. In steps 6 and 7, 
the foreign agent notifies the end system (i.e., mobile) 
of the registration reply. 



[0097] FIG. 1 9 shows directory usage for an end sys- 
tem that is registering from a foreign network. In step 0 
the end system (mobile) solicits an advertisement and 
the foreign agent advertises which provides the end sys- 
tem with information about the network to which the for- 
eign agent belongs. In this case, the network is a foreign 
wireless service provider. In step 1, user registration 
agent (in the end system) incorporates the information 
about the foreign agent and its network and its security 
credentials into a request and sends the request to the 
foreign agent. In step 2, the foreign agent, as a proxy 
registration agent, relays the request to the foreign reg- 
istration server (i.e., the registration server for the for- 
eign wireless service provider. In step 3, the foreign reg- 
istration server accesses the HDD of foreign wireless 
service provider to learn the network to which the end 
system belongs. In step 4, the foreign registration server 
forwards the end system's request to the home registra- 
tion server of the end system's home wireless service 
provider. In step 5, the home registration server access- 
es the FDD of the home registration server to learn at 
least authentication information about the foreign serv- 
ice provider. In step 6, the home registration server ac- 
cesses the subscriber's directory to learn detail sub- 
scriber service profile information (e.g., quality of serv- 
ice options subscribed to, etc.). In step 7, the home reg- 
istration server notifies the foreign registration server of 
the access response. In step 8, the foreign registration 
server forwards to the foreign agent the access re- 
sponse. In step 9, the foreign agent notifies the end sys- 
tem (i.e., mobile) of the registration reply. 
[0098] Protocol handling scenarios for handling bear- 
er data and the associated stacks for transporting bear- 
er data to and from an end system, the protocol stacks 
for the cell architectures using local APs (FIG. 20) and 
remote APs (FIG. 21). 

[0099] FIG. 20 shows the protocol stacks for handling 
communications between an end system (in its home 
network) and a home IWF for End System @ Home. 
FIG. 20 shows the protocol handling for a cell architec- 
ture where the access point and the wireless hub are 
co-located. 

[0100] FIG. 21 shows the protocol handling for a cell 
architecture where the access point is located remotely 
from the wireless hub. As shown, PPP terminates in the 
IWF and the configuration provides direct internet ac- 
cess. The configuration for the case where the PPP 
server is separate from the IWF is described later. 
[0101] In FIG. 21, PPP frames from the end system 
are encapsulated in RLP (radio link protocol) frames 
which are encapsulated at the remote access point in 
MAC frames for communicating with the trunk access 
point (i.e., an access point physically located near the 
wireless hub), the remote access point being coupled to 
the access point by, for example, a wireless truck). The 
access point functions as a MAC layer bridge and relays 
frames from the air link to the foreign agent in the wire- 
less hub. The foreign agent de-encapsulates the RLP 
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frames out of the MAC frames, and using the xtunnel 
protocol, relays the RLP frames to the IWF. A similar, 
albeit reverse, process occurs for transmitting frames 
from the IWF to the end system. 

[0102] If the end system moves to another foreign 
agent, then a new xtunnel will be automatically created 
between the new foreign agent and the IWF, so that PPP 
traffic continues to flow between them, without interrup- 
tion. 

[0103] In the remote AP cell architecture (FIG. 21 ) us- 
ing wireless trunks between the remote AP and the trunk 
AP, the air link between the end system and the access 
point may operate at a different frequency (f 1 ) and use 
a different radio technology as compared to the frequen- 
cy (f2) and radio technology of the trunk. 
-[0104] — FIG-22 shows-the-protocohstacks-fora-roam-™ 
ing end system. The serving IWF uses the l-xtunnel pro- 
tocol between the serving IWF and home IWF The rest 
of the protocol stacks remain unchanged and are not 
shown. This architecture may be simplified by merging 
the serving IWF into the base station, thus eliminating 
the XWD protocol. 

[0105] The RLP layer uses sequence numbers to 
drop duplicate PPP datagrams and provide in-sequence 
delivery of PPP datagrams between the end system and 
the IWF It also provides a configurable keep-alive 
mechanism to monitor link connectivity between the end 
system and the IWF. Additionally, in an alternative em- 
bodiment, the RLP iayer also provides re-transmission 
and flow control services in order to reduce the overall 
bit error rate of the link between the end system and the 
IWF. The RLP between the end system and the IWF is 
started at the beginning of the session and remains ac- 
tive throughout the session and even across hand-off s. 
[01 06] In contrast to the specification in the mobile IP 
RFC (RFC 2003), IP in IP encapsulation is not used for 
tunneling between the foreign agent and the home IWF. 
Instead a new tunneling protocol, implemented on top 
of UDP is used. This tunneling protocol is a simplified 
version of the L2TP protocol. The reasons for this choice 
are as follows. 



3. Using RFC 2003, there is no easy way of creating 
tunnels taking into account quality of service and 
load balancing. In order to take QOS into account, 
it should be possible to set up tunnels over links that 
5 already provide the required QOS. Secondly, using 

RFC 2003, there is no easy way to provide load bal- 
ancing to distribute bearer traffic load over multiple 
links between the base station and the MSC. 

io 4. in order to implement IP in IP encapsulation as 
specified in RFC 2003, developers require access 
to IP source code. In commercial operating sys- 
tems, source code for the TCP/IP stack is generally 
proprietary to other equipment manufacturers. Pur- 

*5 chasing the TCP/IP stack from a vendor and making 
— changes~to theHPHayer-to support-mobileHP tun- 
neling would require a developer to continue sup- 
porting a variant version of the TCP/IP stack. This 
adds cost and risk. 

20 

[0107] While it is noted that the tunneling protocol be- 
tween the base station and the IWF is non-standard and 
that the wireless service provider will not be able to mix 
and match equipment from different vendors, the use of 

25 a non-standard tunneling protocol within a single wire- 
less service provider network is transparent to end sys- 
tems and equipment from other vendors. 
[0108] The new tunneling protocol is based on L2TR 
By itself, L2TP is a heavyweight tunneling protocol so 

30 that L2TP has a lot of overhead associated with tunnel 
creation and authentication, The new tunneling protocol 
of the present invention has less overhead. The new 
xtunnel and l-X tunnel protocol may have the following 
features. 

35 

1 . The xtunnel and l-X tunnel creation adds vendor 
specific extensions to Radius Access Request and 
Radius Access Response messages between the 
base station and the registration server. These ex- 
40 tensions negotiate tunnel parameters and to create 
the tunnel. 



1 . The encapsulation protocol specified in RFC 
2003 does not provide flow control or in-sequence 
delivery of packets. The presently described net- 45 
work may need these services in the tunnel over the 
backhaul. Flow control may be needed to reduce 
the amount of retransmissions over the air link be- 
cause of packet loss due to flow control problems 
over the network between the base station and the 50 
MSC or because of flow control problems in the 
base station or the IWF. 

2. By using a UDP based tunneling protocol, the im- 
plementation can be done at the user level and then 55 
put into the kernel for performance reasons, after it 
has been debugged. 



2. The registration server is able to delegate the ac- 
tual work of tunneling and relaying packets to a dif- 
ferent IP address, and therefore, to a different serv- 
er in the MSC. This permits the registration server 
to do load balancing across multiple IWF servers 
and to provide different QOS to various users. 

3. The xtunnel and l-X tunnel protocol supports in- 
band control messages for tunnel management. 
These messages include echo request/response to 
test tunnel connectivity, disconnect request/re- 
sponse/notify to disconnect the tunnel'and error no- 
tify for error notifications. These messages are sent 
over the tunneling media, for example, UDP/IP. 

4. The xtunnel and l-X tunnel protocol sends pay- 
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load data over the tunneling media, for example, 
UDP/IP. The xtunnei l-X tunnel protocol supports 
flow control and in-sequence packet delivery. 

5. The xtunnei and l-X tunnel protocol may be im- s 
plemented over media other than UDP/I P for quality 
of service 

[0109] The network supports direct internet connec- 
tivity by terminating the PPP in the home IWF and rout- 10 
ing IP packets from the IWF to the internet via a router 
using standard IP routing techniques. Preferably, the 
IWF runs RIP, and the router also runs RIP and possibly 
other routing protocols like OSPF. 

[0110] The network supports a first configuration for is 
a wireless service provider who is also an internet serv- 
ice provider. In this configuration, the home IWF in the 
MSC also functions as a PPP server. This IWF also runs 
internet routing protocols like RIP and uses a router to 
connect to the internet service provider's backbone net- 20 
work. 

[0111] The network supports a second configuration 
for a wireless service provider who wishes to allow end 
systems to connect to one or more internet service pro- 
viders, either because the WSP itself is not ISPs, or be- 25 
cause the WSP has agreements with other ISPs to pro- 
vide access to end users. For example, a wireless serv- 
ice provider may elect to offer network access to an end 
user and may have an agreement with a 3 rd party ISP 
to allow the user who also has an account with the 3 rd 30 
party ISP to access the ISP from the WSP network. In 
this configuration, the PPP server does not run in the 
home IWF installed at the MSC. Instead, a tunneling 
protocol like L2TP (Layer Two Tunneling Protocol) is 
used to tunnel back to the ISP's PPP server. FIG. 10 35 
shows the protocol stacks for this configuration for an 
end system tllat is at home. 

[0112] The location of the home IWF and the ISP PPP 
server remains fixed throughout the PPP session. Also, 
the L2TP tunnel between the IWF and the ISP's PPP 40 
server remains up throughout the PPP session. The 
physical link between the IWF and the PPP server is via 
a router using a dedicated T1 or T3 or frame relay or 
ATM network. The actual nature of the physical link is 
not important from the point of view of the architecture. 45 
[0113] This configuration also supports intranet ac- 
cess. For intranet access, the PPP server resides in the 
corporate intranet and the home IWF uses L2TP to tun- 
nel to it. 

[0114] For a fixed end systenr the protocol handling so 
for intranet or ISP access is as shown in FIG. 23 with 
the difference that the roaming end system uses a serv- 
ing IWF to connect to its home IWF. The protocol han- 
dling between a serving IWF and a home IWF has been 
described earlier. In Figure 23, the home IWF may be 55 
merged into the wireless hub eliminating the X-tunnel 
protocol. Also, the serving IWF may be merged into the 
wireless hub, thus eliminating the X-tunnel protocol. 
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[0115] FIG. 24 shows the protocol stacks used during 
the registration phase (end system registration) for a lo- 
cal AP cell architecture. The stack for a remote AP cell 
architecture is very similar. 

[0116] The scenario shown above is for a roam ina. end 
system. For an end system at home, there is no foreign 
registration server in the registration path. 
[0117] Note the mobility agent in the end system. The 
mobility agent in the end system and foreign agent in 
the wireless hub are conceptually similar to the mobile 
IP RFC 2002. The mobility agent handles network errors 
using time-outs and re-trys. Unlike the known protocol 
stacks for bearer data, RLP is not used. The foreign 
agent and the registration servers use Radius over 
UDP/IP to communicate with each other for registering 
the end system. 

[0118] Several aspects of security must be consid- 
ered. The first, authenticating the identities of the end 
system and the foreign/home networks during the wire- 
less registration phase. Second, authenticating the 
identity of the end system with its PPP server during the 
PPP authentication phase. Third, authentication for 
storing accounting data, for billing and for updating 
home domain information. Fourth, encryption of. bearer 
traffic transmitted to and from the end system. Fifth, en- 
cryption for exchanging billing information across serv- 
ice provider boundaries. 

[0119] Shared secrets are used to authenticate the 
identity of end systems with their home networks and 
the identity of the home and foreign networks with each 
other during wireless registration. 
[0120] End system authentication uses a 128-bit 
shared secret to create an authenticator for its registra- 
tion request. The authenticator is created using the 
known MD5 message digest algorithm as described in 
the mobile IP RFC 2002. Alternatively, a different algo- 
ritm may be used. The shared secret is not sent in the 
registration request by the end system. Only the authen- 
ticator is sent. On receiving the registration request from 
the end system, the home registration server re-com- 
putes the authenticator over the registration request da- 
ta using the shared secret. If the computed authenticator 
value matches the authenticator value sent by the end 
system, the home registration server allows the regis- 
tration process to proceed. If the values do not match, 
the home registration server logs the event, generates 
a security violation alarm and a nak (i.e., a negative ac- 
knowledgment) to the request. 

[0121] In the registration reply, the home registration 
server does the same - that is to say, uses the shared 
secret to create an authenticator for the registration re- 
ply that it sends to the end system. Upon receiving the 
reply, the end system re-computes the authenticator us- 
ing the shared secret. If the computed value does not 
match the authenticator value sent by the home regis- 
tration server in the reply, the end system discards the 
reply and tries again. 

[01 22] These network security concepts are similar to 



EP 0 917 320 A2 



BMSDOCID: <EP 0917320A2_I_> 



17 



EP 0 917 320 A2 



34 



33 

the concepts defined in mobile IP RFC 2002. According 
tothe RFC, a mobility security association exist between 
each end system ant its home network. Each mobility 
security association defines a collection of security con- 
texts. Each security context defines an authentication 
algorithm, a mode, a secret (shared or public-private), 
style of replay protection and the type of encryption to 
use. In the context of the present network, the end sys- 
tem's User-Name (in lieu of the mobile IP home address) 
is used to identify the mobility security association be- 
tween the end system and its home network. Another 
parameter, called the security parameter index (SPI), is 
used to select a security context within the mobility se- 
curity association. In a basic embodiment of the inven- 
tion, only the default mobile IP authentication algorithm 
_4key-edrMD5)„andJhe„default.mode^("prefiXihSuffix").are_ 
supported with 128-bit shared secrets. Network users 
are allowed to define multiple shared secrets with their 
home networks. The mechanism for creating security 
contexts for end users, assigning an SPI to each secu- 
rity context and for setting the contents of the security 
context (which includes the shared secret) and for mod- 
ifying then contents are described below. During regis- 
tration, a 1 28-bit message digest is computed by the end 
system in prefix+suffix mode using the MD5 algorithm. 
The shared secret is used as the prefix and the suffix 
for the data to be protected in the registration request. 
The authenticator thus computed, along with the SPI 
and the User-Name are transmitted in the registration 
request by the end system. Upon receiving the end sys- 
tem's registration request, the foreign registration server 
relays the request along with the authenticator and the 
SPI, unchanged to the home registration server. Upon 
receiving the registration request directly from the end 
system or indirectly via a foreign registration server, the 
home registration server uses the SPI and the User- 
Name to select the security context. The home server 
re-computes the authenticator using the shared secret. 
If the computed authenticator value matches the value 
of the authenticator sent in the request by the end sys- 
tem, the user's identity will have been successfully au- 
thenticated. Otherwise : the home registration server 
naks (negatively acknowledges) the registration request 
sent by the end system. 

[0123] The registration reply sent by the home regis- 
tration server to the end system is also authenticated 
using the algorithm described above. The SPI and the 
computed authenticator value is transmitted in the reg- 
istration reply message by the home server to the end 
system. Upon receiving the reply, the end system re- 
computes the authenticator, and if the computed value 
does not match the transmitted value, it will discard the 
reply and retry. 

[0124] The user's end system has to be configured 
with the shared secret and SPIs for all security contexts 
that the user shares with its registration server(s). This 
configuration information is preferably stored in a Win 
95 registry for Windows 95 based end systems. During 



registration, this information is accessed and used for 
authentication purposes. 

[0125] In the network, Radius protocols are used by 
foreign agent FA to register the end system and to con- 

s figure the xtunnel between the wireless hub and the 
home and serving IWFs on behalf of the end system. 
On receiving a registration request from the end system, 
the FA creates a Radius Access-Request packet, stores 
its own attributes into the packet, copies the end sys- 

10 tern's registration request attributes unchanged into this 
packet and sends the combined request to the registra- 
tion server in the MSC. 

[01 26] Radius authentication requires that the Radius 
client (in this case, tile FA in the base station) and the 

15 Radius server (in this case, the registration server in the 

_ _MSC)_shar_e_a_sec.te.t_f o.r.a uthent ication.p u rposes . JThis„ 
shared secret is also used to encrypt any private infor- 
mation communicated between the Radius client and 
the Radius server. The shared secret is a configurable 

20 parameter. The network follows the recommendations 
in the Radius RFC and uses the shared secret and the 
MD5 algorithm for authentication and for encryption, 
where encryption is needed. The Radius-Access Re- 
quest packet sent by the FA contains a Radius User- 

2S Name attribute (which is provided by the end system) 
and a Radius User-Password attribute. The value of the 
User-Password attribute is also a configurable value 
and encrypted in the way recommended by the Radius 
protocol. Other network specific attributes, which are 

30 non-standard attributes from the point of view of the Ra- 
dius RFC standards, are encoded as vendor specific 
Radius attributes and sent in the Access-Request pack- 
et. 

[0127] The following attributes are sent by the FA to 
35 its registration server in the Radius Access-Request 
packet. 

1 . User-Name Attribute. This is the end system's us- 
er-name as supplied by the end system in its regis- 

40 tration request. 

2. User-Password Attribute. This user password is 
supplied by the base station/wireless hub on behalf 
of the user. It is encoded as described in the Radius 

45 EFC using the secret shared between the base sta- 
tion and its registration server. 

3. NAS-Port. This is the pon on the base station. 

so 4. NAS-IP-Address. This is the IP address of the 

base station. 

5. Service-Type. This is framed service. 

55 6. Framed Protocol. This is a PPP protocol. 

7. Xtunnel Protocol Parameters. These parameters 
are sent by the base station to specify the parame- 
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ters necessary to setup the xtunnel protocol on be- 
half of the end system. This is a vendor-specific at- 
tribute. 

8. AP-IP-Address. This is the IP address of the AP 
through which the user is registering. This is a ven- 
dor-specific attribute. 



1 . Home Registration Server IP Address. This is the 
IP address of the home registration server to for- 
ward the registration request. 
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2. Foreign Registration Server Machine Id. This is 
the machine ID of the foreign registration server in 
SMTP (simplified mail transfer protocol) format (e. 
g., machine @fqdn where machine is the name of 
the foreign registration server machine and fqdn is 
the fully qualified domain name of the foreign reg- 
istration server's domain). 

3. Tunneling Protocol Parameters. These are pa- 
rameters for configuring the tunnel between the 
serving IWF and the home I WF on behalf of the end 
system. These include the tunneling protocol to be 
used between them and the parameters for config- 
uring the tunnel. 

4. Shared Secret This is the shared secret to be 
used tor authentication between the foreign regis- 
tration server and the home registration server. This 
secret is used for computing the Radius User-Pass- 
word attribute in the Radius packet sent by the for- 
eign registration server to the home registration 
server. It is defined between the two wireless serv- 
ice providers. 

5. User-Password. This is the user password to be 
used on behalf of the roaming end system. This us- 
er password is defined between the two wireless 
service providers. This password is encrypted using 
the shared secret as described in the Radius RFC. 

6. Accounting Parameters. These are parameters 
for configuring accounting on behalf of the end sys- 
tem that is registering. These parameters are sent 
by the registration server to its IWF for configuring 
accounting on behalf of the end system. 

[01 30] Using this information, the foreign registration 
server creates a Radius Access-Request, adds its own 
registration and authentication information into the Ra- 
dius Access-Request, copies the registration informa- 
tion sent by the end system unchanged into the Radius 
Access-Request and sends the combined request to the 
home registration server. 

[0131] Upon receiving the Radius-Access Request 
from the foreign registration server (for a roaming end 
system) or directly from the FA (for an end system at 
home), the home registration server consults its own di- 
rectory server for the shared secrets to verify the identity 
of the end system and the identity of the foreign regis- 
tration server in a roaming scenario by re-computing au- 
thenticators. 

[0132] After processing the request successfully, the 
home registration server creates a Radius Access-Ac- 
cept response packet and sends it to the foreign regis- 
tration server if the end system is roaming, or directly to 
the FA from which it received the Radius Access-Re- 
quest. The response contains the registration reply at- 
tribute that the FA relays to the end system. 



9. AP-MAC-Address. This is the MAC address of 

the AP through which the user is registering. This to 
is a vendor-specific attribute. 

10. End system's Registration Request The regis- 
tration request from the end system is copied un- 
changed into this vendor specific attribute. is 

[01 28] The following attributes are sent to the FA from 
the registration server in the Radius Access-Response 
packet. 

20 

1. Service Type. This is a framed service. 

2. F famed-Protocol. This is a PPP. 

3. Xtunnel Protocol Parameters. These parameters 25 
are sent by the registration server to specify the pa- 
rameters necessary to setup the xtunnel protocol 

on behalf of the end system. This is a vendor-spe- 
cific attribute. 

30 

4. Home Registration Server's Registration Reply. 
This attribute is sent to the FA from the home reg- 
istration server. The FA relays this attribute un- 
changed to the end system in a registration reply 
packet. If there is a foreign registration server in the 35 
path, this attribute is relayed by it to the FA un- 
changed. It is coded as a vendor-specific attribute. 

[01 29] To provide service to roaming end systems, the 
foreign network and the home network are authenticat- 40 
ed to each other for accounting and billing purposes us- 
ing the Radius protocol for authentication and configu- 
ration. This authentication is performed at the time of 
end system registration. As described earlier, when the 
registration server in the foreign network receives a reg- 45 
istration request from an end system (encapsulated as 
a vendor specific attribute in a Radius-Access Request 
packet by the FA), it uses the end system's User-Name 
to determine the identity of the end system's home reg- 
istration server by consulting its home domain directory so 
HDD. The following information is stored in home do- 
main directory HDD and accessed by the foreign regis- 
tration server in order to forward the end system's reg- 
istration request. 
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[0133] If the request can not be processed success- 
fully, the home registration server creates a Radius Ac- 
cess-Reject response packet and sends it to the foreign 
registration server if the end system is roaming, or di- 
rectly to the FA from which it received the Radius Ac- 
cess-Request. The response contains the registration 
reply attribute that the FA will relays to the end system. 
[0134] In a roaming scenario, the response from the 
home registration server is received by the foreign reg- 
istration server. It is authenticated by the foreign regis- 
tration server using the shared secret. After authenticat- 
ing, the foreign registration server processes the re- 
sponse, and in turn it generates a Radius response 
packet (Accept or Reject) to send to the FA. The foreign 
registration server copies the registration reply attribute 
-f rorruth e-h om e^re g i strat ion„s e rv.e rls_Badj it sjre sp_orv s e : __ 
packet, unchanged, into its Radius response packet. 
[0135] When the FA receives the Radius Access-Re- 
sponse or Radius Access-Reject response packet, it 
creates a registration reply packet using the registration 
reply attributes from the Radius response, and sends 
the reply to the end system, thus completing the round 
trip registration sequence. 

[0136] Mobile IP standards specifies that replay pro- 
tection for registrations are implemented using time 
stamps, or optionally, using nonces. However, since re- 
play protection using time stamps requires adequately 
synchronized time-of-day clocks between the corre- 
sponding nodes, the present invention implements re- 
play protection during registration, using nonces even 
though replay protection using time stamps is manda- 
tory in the Mobile IP standards and the use nonces is 
optional. However, replay protection using time stamps 
as an alternative embodiment is envisioned. 
[0137] The style of replay protection used between 
nodes is stored in the security context in addition to the 
authentication context, mode, secret and type of encryp- 
tion. 

[0138] The network supports the use of PPP PAP 
(password authentication) and CHAP (challenge au- 
thenticated password) between the end system and its 
PPP server. This is done independently of the registra- 
tion and authentication mechanisms described earlier. 
This allows a private intranet or an ISP to independently 
verify the identity of the user. 

[0139] Authentication for accounting and directory 
services is described below with respect to accounting 
security. Access to directory servers from network 
equipment in the same MSC need not be authenticated. 
[01 40] The network supports encryption of bearer da- 
ta sent between the end system and the home I WF. End 
systems negotiate encryption to be on or off by selecting 
the appropriate security context. Upon receiving the reg- 
istration request, the home registration server grants the 
end system's request for encryption based upon the se- 
curity context. In addition to storing the authentication 
algorithm, mode, shared secret and style of replay pro- 
tection, the security context is also used to specify the 
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style of encryption algorithm to use. If encryption is ne- 
gotiated between the end system and the home agent, 
then the complete PPP frame is so encrypted before en- 
capsulation in RLP. 

[0141] The IWF, the accounting server and the billing 
system are part of the same trusted domain in the MSC. 
These entities are either connected on the same LAN 
or part of a trusted intranet owned and operated by the 
wireless service provider. Transfer of accounting statis- 
tics between the IWF and the accounting server and be- 
tween the accounting server and the customer's billing 
system need not be encrypted using Internet IP security 
protocols like IP-Sec. 

[0142] The network makes it more difficult to monitor 
the location of the end system because it appears that 
all PPP f rames going t o an d from the end system go 
through the home IWF regardless of the actual location 
of the end system device, 

[0143] Accounting data is collected by the serving 
IWF and the home IWF in the network. Accounting data 
collected by the serving IWF is sent to an accounting 
server in the serving IWF's MSC. Accounting data col- 
lected by the home IWF is sent to an accounting server 
in the home IWF's MSC. The accounting data collected 
by the serving IWF is used by the foreign wireless serv- 
ice provider for auditing and for settlement of bills across 
wireless service provider boundaries (to support roam- 
ing and mobility). The accounting data collected by the 
home IWF is used for billing the end user and also for 
settlement across wireless service provider boundaries 
to handle roaming and mobility. 

[0144] Since all data traffic flows trough the home 
IWF, regardless of the end system's location and the for- 
eign agent's location, the home IWF has all the informa- 
tion to generate bills for the customer and also settle- 
ment information for the use of foreign networks. 
[01 45] The serving IWF and the home IWF preferably 
use the Radius accounting protocol for sending ac- 
counting records for registered end systems. The Radi- 
us accounting protocol is as documented in a draft IETF 
RFC. For the present invention, the protocol has to be 
extended by adding vendor specific attributes for the 
network and by adding check-pointing to the Radius Ac- 
counting protocol. Check-pointing in this context refers 
to the periodic updating of accounting data to minimize 
risk of loss of accounting records. 
[0146] The Radius accounting protocol runs over 
UDP/I P and uses re-trys based on acknowledgment and 
time outs. The Radius accounting client (serving IWFs 
or home IWFs) send UDP accounting request packets 
to their accounting servers which send acknowledg- 
ments back to the accounting clients. 
[0147] In the network, the accounting clients (serving 
IWF and the home IWF) emit an accounting start indi- 
cation at the start of the user's session and an account- 
ing stop indication at the end of the user's session. In 
the middle of the session, the accounting clients emit 
accounting checkpoint indications. In contrast, the Ra- 
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dius accounting RFC does not specify an accounting 
checkpoint indication. The software of the present in- 
vention creates a vendor specific accounting attribute 
for this purpose. This accounting attribute is present in 
all Radius Accounting-Request packets which have Ac- 5 
ct-Status-Type of Start (accounting start indications). 
The value of this attribute is used to convey to the ac- 
counting server whether the accounting record is a 
check-pointing record or not. Check-pointing account- 
ing reports have a time attribute and contain cumulative 10 
accounting data from the start of the session. The fre- 
quency of transmitting check-point packets is configura- 
ble in the present invention. 

[0148] The serving IWF and the home IWF are con- 
figured by their respective registration servers for con- is 
necting to their accounting servers during the registra- 
tion phase. The configurable accounting parameters in- 
clude the IP address and UDP port of the accounting 
server, the frequency of check-pointing, the session/ 
multi-session id and the shared secret to be used be- 20 
tween the accounting client and the accounting server. 
[0149] The network records the following accounting 
attributes for each registered end system. These ac- 
counting attributes are reported in Radius accounting 
packets at the start of the session, at the end of the ses- 2s 
sion and in the middle (check-point) by accounting cli- 
ents to their accounting servers. 

1. User Name. This is like the Radius User-Name 
attribute discussed above. This attribute is used to 30 
identify the user and is present in all accounting re- 
ports. The format is n user@domain" where domain 

is the fully qualified domain name of the user's 
home. 

35 

2. NAS IP Address. This is like the Radius IMAS-IP- 
Address attribute discussed above. This attribute is 
used to identify the IP address of the machine run- 
ning the home IWF or the serving IWF. 

40 

3. Radio Port. This attribute identifies the radio port 
on the access point providing service to the user. 
This attribute is encoded as a vendor specific at- 
tribute. 

45 

4. Access Point IP Address. This attribute identifies 
the IP address of the access point providing service 
to the user. This'attribute is encoded as a vendor 
specific attribute. 

so 

5. Service Type. This is like the Radius Service- 
Type attribute described above. The value of this 
attribute is Framed. 

6. Framed Protocol. This is like the Radius Framed- ss 
Protocol attribute described above. The value of 
this attribute is set to indicate PPR 
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7. Accounting Status Type. This is like the Radius 
Acct-Status-Type attribute described above. The 
value of this attribute may be Start to mark the start 
of a user's session with the Radius client and Stop 
to mark the end of the user's session with the Ra- 
dius client. For accounting clients, the Acct-Status- 
Type/Start attribute is generated when the end sys- 
tem registers. The Acct-Status-type/Stop attribute 
is generated when the end system de-registers for 
any reason. For checkpoints, the value of this at- 
tribute is also Start and the Accounting Checkpoint 
attribute is also present. 

8. Accounting Session Id. This is like the Radius Ac- 
ct-Session-ld described above. In a roaming sce- 
nario, this session id is assigned by the foreign reg- 
istration server when the end system issues a reg- 
istration request. It is communicated to the home 
registration server by the foreign registration server 
during the registration sequence. The home net- 
work and the foreign network both know the Acct- 
Session-ld attribute and are able to emit this at- 
tribute while sending accounting records to their re- 
spective accounting servers. In a "end system-at- 
home" scenario, this attribute is generated by the 
home registration server. The registration server 
communicates the value of this attribute to the IWF 
which emits it in all accounting records. 

9. Accounting Multi-Session Id This is like the Ra- 
dius Acct-Multi-Session-ld discussed above. This id 
is assigned by the home registration server when a 
registration request is received from a FA directly or 
via a foreign registration server on behalf of an end 
system. It is communicated to the foreign registra- 
tion server by the home registration server in the 
registration reply message. The registration server 
(s) communicates the value of this attribute to the 
IWF(s) which emit it in all accounting records. 

[0150] With true mobility added to the architecture, 
the id is used to relate together the accounting records 
from different I WFs for the same end system if the end 
system moves from one IWF to another. For hand-offs 
across IWF boundaries, the Acct-Session-ld is different 
for accounting records emanating from different I WFs. 
However, the Acct-Multi-Session-ld attribute is the 
same for accounting records emitted by all I WFs that 
have provided service to the user Since the session id 
and the multi-session id-are known to both the foreign 
network and the home network, they are able to emit 
these attributes in accounting reports to their respective 
accounting servers. With the session id and the multi- 
session id, billing systems are able to correlate account- 
ing records across IWF boundaries in the same wireless 
service provider and even across wireless service pro- 
vider boundaries. 
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1 . Accounting Delay Time. See Radius Acct- Delay- 
Time attribute. 

2. Accounting Input Octets. See Radius Acct-lnput- 
Octets. This attribute is used to keep track of the 5 
number of octets sent by the end system (input to 
the network from the end system). This count is 
used totrackthe PPP frames only. The air link over- 
head, or any overhead imposed by RLP, etc. and is 

not counted. to 

3. Accounting Output Octets. See Radius Acct-Out- 
put-Octets. This attribute is used to keep track of 
the number of octets sent to the end system (output 
from the network to the end system). This count is *5 

used totrack the PPP frames only. Th e air link o v er- 

head, or any overhead imposed by RLP, etc. and is 

not counted. 

4. Accounting Authentic. See Radius Acct-Authen- 20 
tic attribute. The value of this attribute is Local or 
Remote depending on whether the serving IWF or 
the home IWF generates the accounting record. 

5. Accounting Session Time. See Radius Acct-Ses- 25 
sion-Time attribute. This attribute indicates the 
amount of time that the user has been receiving 
service. If sent by the serving IWF, this attribute 
tracks the amount of time that the user has been 
receiving service from that serving IWF. If sent by 30 
the home IWF, this attribute tracks the amount of 
time that the user has been receiving service from 
the home IWF. 

6. Accounting Input Packets. See Radius Acct-in- 35 
put-Packets attribute. 3. This attribute indicates the 
number of packets received from the end system. 
For a serving IWF, this attribute tracks the number 

of PPP frames input into the serving IWF from an 
end system. For a home IWF, this attribute tracks 40 
the number of PPP frames input into the home IWF 
from an end system. 

7. Accounting Output Packets. See Radius Acct- 
Output-Packets attribute. This attribute indicates 45 
the number of packets sent to the end system. For 

a serving IWF, this attribute tracks the number of 
PPP frames output by the serving IWF to the end 
system. For a home IWF, this attribute tracks the 
number of PPP frames sent to the end system from so 
the home IWF. 

8. Accounting Terminate Cause. See Radius Acct- 
Terminate-Cause attribute. This attribute indicates 
the reason why a user session was terminated. In 55 
addition, a specific cause code is also present to 
provide additional details. This attribute is only 
present in accounting reports at the end of the ses- 



9. Network Accounting Terminate Cause. This at- 
tribute indicates a detailed reason for terminating a 
session. This specific attribute is encoded as a ven- 
dor specific attribute and is only reported in a Radi- 
us Accounting attribute at the end of session The 
standard Radius attribute Acct-Tennhate-Cause is 
also present. This attribute provides specific cause 
codes, not covered by the Acct-Terminate-Cause 
attribute. 

10. Network Air link Access Protocol. This attribute 
indicates the air link access protocol used by the 
end system. This attribute is encoded as a vendor 
sp ecific attribute. „ _ 



11. Network Backhaul Access Protocol. This at- 
tribute indicates the backhaul access protocol used 
by the access point to ferry data to and from the end 
system. This attribute is encoded as a vendor spe- 
cific attribute. 

1 2. Network Agent Machine Name. This attribute is 
the fully qualified domain name of the machine run- 
ning the home IWF or the serving IWF This specific 
attribute is encoded in vendor specific format. 

13 Network Accounting Check-point Since the Ra- 
dius accounting RFC does not define a check-point 
packet, the present network embodiment uses a 
Radius accounting start packet with this attribute to 
mark a check-point. The absence of a check-point 
attribute means a conventional accounting start 
packet. The presence of this attribute in a account- 
ing start packet means a accounting check-point 
packet. Accounting stop packets do not have this 
attribute. 

[0151] In the preferred embodiment, every account- 
ing packet and the corresponding reply must be authen- 
ticated using MD5 and a shared secret. The IWFs are 
configured with a shared secret that are used by them 
for authentication during communication with their Ra- 
dius accounting server. The shared secrets used by the 
IWFs for communicating with accounting servers are 
stored in the home/foreign domain directory located in 
the MSG. The shared secrets for accounting security are 
communicated to the IWFs by their registration servers 
during the end system registration sequence. 
[0152] The accounting server software runs in a com- 
puter located in the MSC. The role of the accounting 
server in the system is to collect raw accounting data 
from the network elements (the home and the serving 
IWFs), process the data and store it for transfer to the 
wireless service provider's billing system. The account- 
ing server does not include a billing system. Instead, it 
includes support for an automatic or manual accounting 
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data transfer mechanism. Using the automatic account- 
ing data transfer mechanism, the accounting server 
transfers accounting records in AM A billing format to the 
customer's billing System over a TCP/IP transport. For 
this purpose, the system defines AMA billing record for- s 
mats for packer data. Using the manual transfer mech- 
anism, customers are able to build a tape to transfer ac- 
counting records to their billing system. In order to build 
the tape to their specifications, customers are provided 
with information to access accounting records so that 10 
they may process them before writing them to tape. 
[0153] In FIG. 25, the raw accounting data received 
by the accounting server from the home or serving I WFs 
are processed and stored by the accounting server. The 
processing done by the accounting server includes fil- is 
tering, compression and correlation of the raw account- 
ing data received from the IWR A high availability file 
server using dual active/standby processors and hot 
swappable RAID disks is used for buffering the account- 
ing data while it is transiting through the accounting 20 
server. 

[0154] The accounting server delays processing of 
the raw accounting data until an end system has termi- 
nated its session. When an end system terminates its 
session, the accounting server processes the raw ac- 2s 
counting data that it has collected for the session and 
stores an accounting summary record in a SQL data- 
base. The accounting summary record stored in the 
SQL data base points to an ASNI.1 encoded file. This 
file contains detailed accounting information about the 30 
end system's session. The data stored in the accounting 
server is then transferred by the billing data transfer 
agent to the customer's billing system. Alternatively, the 
wireless service provider may transfer the accounting 
data from the SQL database and/or the ASN. 1 encoded 35 
file to the billing system via a tape, The data base 
scheme and the format of the ASN.1 encoded file are 
documented and made available to customers for this 
purpose. If the volume of processed accounting data 
stored in the accounting system exceeds a high water 40 
mark, the accounting server generates an NMS alarm. 
This alarm is cleared when the volume of data stored in 
the accounting server falls below a low water mark. The 
high and low water marks for generating and clearing 
the alarm are configurable. The accounting server also 45 
generates an NMS alarm if the age of the stored ac- 
counting data exceeds a configurable threshold. Con- 
versely, the alarm is cleared, when the age of the ac- 
counting data falls below the threshold. 
[0155] The subscriber directory is used to store infor- so 
mation about subscribers and is located in the home net- 
work. The home registration server consults this direc- 
tory during the registration phase to authenticate and 
register an end system. For each subscriber, the sub- 
scriber directory stores the following information. 55 

1. User-Name. This field in the subscriber record 
will be in SMTP format (e.g., user@fqdn) where the 
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user sub-field will identify the subscriber in his or 
her wireless home domain and the fqdn sub-field 
will identify the wireless home domain of the sub- 
scriber. This field is sent by the end system in its 
registration request during the registration phase. 
This field is assigned by the wireless service pro- 
vider to the subscriber at the time of subscription to 
the network service. This field is different than the 
user name field used in PPP. 

2. Mobility Security Association. This field in the 
subscriber record contains the mobility security as- 
sociation between the subscriber and his or her 
home network. As described above, a mobility se- 
curity association exists between each subscriber 
and its home registration server. The mobility secu- 
rity association defines a collection of security con- 
texts. Each security context defines an authentica- 
tion algorithm, an authentication mode, a shared 
secret, style of replay protection and the type of en- 
cryption (including no encryption) to use between 
the end system and its home server. During regis- 
tration, the home registration server retrieves infor- 
mation about the subscriber's security context from 
the subscriber directory using the User-Name and 
the security parameter index (SPl) supplied by the 
end system in its registration request. The informa- 
tion in the security context is used for enforcing au- 
thentication, encryption and replay protection dur- 
ing the session. The mobility security association is 
created by the wireless service provider at the time 
of subscription. It is up to the wireless service pro- 
vider to permit the subscriber to modify this associ- 
ation either by calling up a customer service repre- 
sentative or by letting subscribers access to a se- 
cure Web site. The Web site software will export 
web pages which the wireless service provider may 
make accessible to subscribers from a secure web 
server. In this way, subscribers are able to view/ 
modify the contents of the mobility security associ- 
ation in addition toother subscriber information that 
the service provider may make accessible. 

3. Modem MAC Address. This field contains the 
MAC address of the modem owned by the subscrib- 
er. In addition to the shared secret, this field is used 
during registration to authenticate the user. It is pos- 
sible to turn off MAC address based authentication 
on a per user basis. The MAC address is commu- 
nicated to the home registration server during reg- 
istration. 

4. Enable MAC Address Authentication. This field 
is used to determine if MAC address based authen- 
tication is enabledor disabled. If enabled, the home 
registration server checks the MAC address of the 
registering end system against this field to validate 
the end system's identity. If disabled, then no check- 
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ing 



is done. 



5. Roaming Enabled Flag. If this field is set to ena- 
bled, then the end system is allowed to roam to for- 
eign networks. If this field is disabled, then the end s 
system is not permitted to roam to foreign networks. 



[0157] The following information is stored in the HDD. 

1. Home Domain Name. This field is used as the 
key to search the HDD for an entry that matches the 
fully qualified home domain name provided by the 
end system in its registration request. 



6. Roaming Domain List This field is meaningful on- 
ly if the Roaming Enabled Flag is set to enabled. 
This field contains a list of foreign domains that the 10 
end system is allowed to roam to. When the con- 
tents of this list is null and the Roaming Enabled 
Flag is set to enabled, the end system is allowed to 
roam freely. 

15 

7^Sewice~Eriable/DisabIe^FlagJTh\sJie\ti may^be 

set to disabled by the system administrator to disa- 
ble service to a subscriber. If this field is disabled, 
then the subscriber is be permitted to register for 
service. If the subscriber is registered and the value 20 
of this field is set to disabled, then the subscriber's 
end system is immediately disconnected by the net- 
work. 

8. Internet Sen/ice Provider Association. This field 25 
contains information about the subscriber's internet 
service provider. This information is used by the 

I WF during the PPP registration phase to perform 
authentication with the internet service provider on 
behalf of the end system and also to create a L2TP 30 
tunnel between the IWF and the internet service 
provider's PPP server. This field contains the iden- 
tity of the subscriber's ISP. The IWF uses this infor- 
mation to access the ISP directory for performing 
authentication and setting up the L2TP tunnel on 35 
behalf of the end system. 

9. Subscriber's Name & Address Information. This 
field contains the subscriber's name, address, 
phone, fax, e-mail address, etc. 40 

[0156] The home domain directory (HDD) is used by 
the registration server to retrieve parameters about the 
end system to complete registration on behalf of the end 
system. Using this information, the registration server 45 
determines if the end system is registering at home or 
if the end system is a roaming end system. In the former 
case ; the registration server assumes the role of a home 
registration server and proceed with end system regis- 
tration. In the latter case : the registration server as- so 
sumes the role of a foreign registration server and, act- 
ing as a Radius proxy, it forwards the request to the real 
home registration server whose identity it gets from this 
directory. For roaming end system, the parameters 
stored in the HDD include the IP address of the home 55 
registration server, the home-foreign shared secret, the 
home-serving IWF tunnel configuration etc. The HDD is 
located in the MSC. 



2. Proxy Registration Request. This field is used by 
the registration server to determine if it should act 
as a foreign registration server and proxy the end 
system's registration request to the real home reg- 
istration server. 

3. Home Registration Server DNS Name. If the 
proxy registration request flag is TRUE, this field is 
us ed.to access the.DN S_n am e oUhe.reaLhome.reg^ 
istration server. Otherwise, this field is ignored. The 
DNS name is translated to an IP address by the for- 
eign registration server. The foreign registration 
server uses the I P address to relay the end system's 
registration request. 

4. Foreign Domain Name. If the proxy registration 
request flag is TRUE, this field is used to identify 
the foreign domain name to the end system's home 
registration server. Otherwise, this field is ignored. 
The foreign registration server uses this information 
to create the foreign server machine id in SMTP for- 
mat, for example, machine@fqdn. This machine id 
is sent to the home registration server by the foreign 
registration, server in the Radius-Access Request. 

5. Shared Secret. If the proxy registration request 
flag is TRUE, the shared secret is used between the 
foreign and home registration servers to authenti- 
cate their identity with each other Otherwise this 
field is ignored. 

6. Tunneling Protocol Parameters. This field is used 
to store parameters to configure the tunnels to pro- 
vide service to the end system. For an end system 
at home, this includes information on tunnel param- 
eters between the base station and the home IWF 
and from the home IWF to the PPP server. For a 
foaming end system, this includes tunneling param- 
eters from the base station to the serving IWF and 
from the serving IWF to the home IWF. At a mini- 
mum, for each tunnel this field contains the type of 
tunneling protocol to use and any tunneling protocol 
specific parameters. For example, this field may 
contain the identifier for the tunneling protocol L2TP 
and any additional parameters required to configure 
the L2TP runnel between the IWF and its peer. 

7. Accounting Server Association This field is used 
to store information needed by the IWF to generate 
accounting data on behalf of the end system. It con- 
tains the name of the accounting protocol (e.g. RA- 
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DIUS), the DNS name of the accounting server and 
additional parameters specific to the accounting 
protocol like the UDP port number, the shared se- 
cret that the I WF must use in the Radius Accounting 
protocol, the frequency of check-pointing, the seed $ 
for creating the session/multi-session id, etc. The 
accounting server's DNS name is translated to the 
accounting server's IP address, which is sent to the 
IWR 

10 

[01 58] For wireless service providers that have roam- 
ing agreements with each other, the HDD is used for 
authentication and to complete the registration process. 
If an end system roams from its home network to a for- 
eign network, the foreign registration server in that net- is 
work consults the HDD in its MSC to get information 
about the visiting end system's home registration and to 
authenticate the home network before it provides serv- 
ice to the visiting end system. 

[0159] The software for home domain directory man- 20 
agement preferably provides a graphical user interlace 
(GUI) based HDD management interface for system ad- 
ministrators. Using this GUI, system administrators are 
able to view and update entries in the HDD. This GUI is 
not intended for use by foreign wireless network service 25 
providers to perform remote updates based on roaming 
agreements. It is only intended for use by trusted per- 
sonnel of the home wireless service provider operating 
behind fire walls 

[0160] The foreign domain directory (FDD) provides 30 
functionality that is the reverse of the home domain di- 
rectory. The FDD is used by the home registration server 
to retrieve parameters about The foreign registration 
server and the foreign network in order to authenticate 
the foreign network and create a tunnel between a serv- 35 
ing I WF and a home IWR These paramaters include the 
home-foreign shared secret, the home I WF-serving IWF 
tunnel configuration, etc. The FDD is preferably located 
in the home registration server's MSC. The FDD is used 
by home registration servers for registering roaming end 40 
systems. 

[0161] The following information will be stored in the 
FDD. 

1 . Foreign Domain Name, This field is used as the 45 
key to search the FDD for an entry that matches the 
fully qualified domain name of the foreign registra- 
tion server relaying the registration request. 

2. Shared Secret This is the shared secret used 50 
between the foreign and home registration servers 

to authenticate their identity mutually with each oth- 
er. 

3. Home IWF-Serving fWF Tunneling Protocol Pa- 55 
rameters. This field is used to store parameters to 
configure the tunnel between the home IWF and the 
serving IWR At a minimum, this field contains the 



type of tunneling protocol to use and any tunneling 
protocol specific parameters. For example, this field 
may contain the identifier for the tunneling protocol 
L2TP and any additional parameters required to 
configure the L2TP tunnel between the serving IWF 
and the home IWF. 

4. Accounting Server Association This field is used 
to store information needed by the home IWF to 
generate accounting data on behalf of the end sys- 
tem. It contains the name of the accounting protocol 
(e.g. RADIUS), the DNS name of the accounting 
server and additional parameters specific to the ac- 
counting protocol like the UDP port number, the 
shared secret that the IWF must use in the Radius 
Accounting protocol, the frequency of check-point- 
ing, the seed for creating the session/multi-session 
id, etc. The accounting server's DNS name is trans- 
lated to the accounting server's IP address., which 
is sent to the foreign agent. 

[0162] For wireless service providers that have roam- 
ig agreements with each other, the FDD is used to do 
authentication and complete the registration process. If 
an end system roams from its home network to a foreign 
network, the registration server in the home network 
consults the FDD in its MSC to get information and au- 
thenticate the foreign network providing service to the 
end system. 

[0163] The foreign domain directory management 
software provides a graphical user interface (GUI) 
based FDD management interface for system adminis- 
trators. Using this GUI, system administrators are able 
to view and update entries in the FDD. This GUI is not 
intended for use by foreign wireless network service pro- 
viders to perform remote updates based on roaming 
agreements. It is only intended for use by trusted per- 
sonnel of the home wireless service provider operating 
behind firewalls. 

[0164] The internet service provider directory (ISPD) 
is used by the home IWF to manage connectivity with 
ISPs that have service agreements with the wireless 
service provider so that subscribers may access their 
ISPs using the network. For each subscriber, the sub- 
scriber directory has an entry for the subscriber's ISP. 
This field points to an entry in the ISPD. The home IWF 
uses this information to set up the connection to the ISP 
on behalf of the subscriber. 

[0165] The network architecture supports roaming. In 
order for roaming to work between wireless service pro- 
viders, the architecture must support the setting up of 
roaming agreements between wireless service provid- 
ers. This implies two things: (1) updating system direc- 
tories across wireless service providers and (2) settle- 
ment ol bills between service providers, 
[0166] In order to allow subsc rib ers access to internet 
service providers, the architecture supports roaming 
agreements with internet service providers. This implies 
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that the architecture must be able to send data to and 
receive data from ISP PPP servers (i.e., that support in- 
dustry standard protocols tike PPP, L2TP and Radius). 
It also implies that the architecture handles directory up- 
dates for ISP access and settlement ol bills with ISPs. 
[0167] When roaming agreements are established 
between two wireless service providers, both providers 
have to update their home and foreign domain directo- 
ries in order to support authentication and registration 
functions for end systems visiting their networks from 
the other network. At a minimum, the architecture of the 
present embodiment supports manual directory up- 
dates. When a roaming agreement is established be- 
tween two wireless service providers, then the two par- 
ties to the agreement exchange information for populat- 
ing their ^home and4oreign»domain directories.^The ac-^ 
tual updates of the directories is done manually by the 
personnel of the respective service providers. If later, 
the information in the home and foreign domain direc- 
tories needs to be updated, the two parties lo the agree- 
ment exchange the updated information and then man- 
ually apply their updates to the directories. 
[0168] In an alternative embodiment, the directory 
management software incorporates developing stand- 
ards in the IETF to enable roaming between internet 
service providers and to enable ISPs to automatically 
manage and discover roaming relationships. This 
makes annual directory management no longer neces- 
sary. The network system automatically propagates 
roaming relationships, and discovers them, to authenti- 
cate and register visiting end systems. 
[0169] At a minimum, the network architecture just 
processes and stores the accounting data and makes 
the data available to the wireless service provider's bill- 
ing system. It is up to the billing system to handle set- 
tlement of bills for roaming. 

[0170] In an alternative embodiment, developing 
standards in the IETF to handle distribution of account- 
ing records between internet service providers are in- 
corporated into the network architecture to enable ISPs 
to do billing settlement for roaming end systems. 
[0171] The system software supports access to ISPs 
and private intranets by supporting L2TP between the 
home IWF and the ISPs or intranet PPP server. The in- 
ternet service provider directory contains information 
useful to the IWF for creating these tunnels. As access 
agreements between the wireless service provider and 
internet service providers are put in place, this directory 
is updated manually by the wireless service, provider's 
personnel. Automatic updates and discovery of access 
relationships between the wireless service provider and 
internet service providers are presently contemplated 
and implemented as the internet standards evolve. 
While accessing an internet service provider, the sub- 
scriber receives two bills - one from the wireless service 
provider for the use of the wireless network and the sec- 
ond from the internet service provider. Although com- 
mon billing that combines both types of charges is not 
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handled by the minimum embodiment software, it is con- 
templated that the software will take advantage of inter- 
net standards for billing settlement as they evolve so 
that subscribers may receive a common bill based on 
roaming agreements between the ISP and wireless 
service providers. 

[0172] The system includes a element management 
system for managing the network elements. From the 
element manager, system administrators perform con- 
figuration, performance and fault/alarm management 
functions. The element management applications run 
on top of a web browser. Using a web browser, system 
administrators manage the network from anywhere that 
they have TCP/IP access. The element manager also 
performs an agent role for a higher level manager. In 
this role it exports an SNMP^Ml B for alarm and fault mon-^ 
itoring. 

[0173] A higher level SNMP manager is notified of 
alarm conditions via SNMP traps. The higher level 
SNMP manager periodically polls the element manag- 
er's Ml B for the health and status of the network. System 
management personnel at the higher level manager are 
able to view an icon representation of the network and 
its current alarm state. By pointing and clicking on the 
network element icon, systems management personnel 
execute element management applications using a web 
browser and perform more detailed management func- 
tions. 

[0174] Inside the network management of the physi- 
cal and logical network elements is performed using a 
combination of the SNMP protocol and internal manage- 
ment application programming interfaces. Applications 
in the element manager use SNMP or other manage- 
ment APIs to perform network management functions. 
[0175] Architecturally, the element management sys- 
tem includes of two distinct sets of functional elements. 
The first set of functional elements, including the con- 
figuration data server, performance data monitor and 
health/status monitor and network element recovery 
software, executes on an HA server equipped with RAID 
disks. The second set of functional elements, including 
the management applications, executes on a dedicated, 
non-HA management system. Even if the element man- 
ager System becomes non-operational, the network el- 
ements continue to be able to run and report alarms and 
even be able to recover from fault conditions. However, 
since all the management applications execute in the 
non-HA element manager, if the element manager goes 
down, then recovery actions requiring human interven- 
tion are not possible until the element manager be- 
comes operational. 

[0176] The wireless hubs (WHs) in the base stations 
are typically owned by a wireless service provider 
(WSP), and they are connected to the WSP's registra- 
tion server (RS) either via point-to-point links, intranets 
or the internet. The WSP's registration server is typically 
a software module executing on a processor to perform 
certain registration functions. Inter-working function 
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units (IWF units) are typically software modules execut- 
ing on a processor to perform certain interfacing func- 
tions. fWF units are typically connected to the registra- 
tion servers via intranets/WAN, and the IWF units are 
typically owned by the WSR However, the IWF units s 
need not be located within the same LAN as the regis- 
tration servers. Typically, accounting and directory serv- 
ers (also software modules executing on a processor) 
are connected to the registration servers via a LAN in 
the service provider's Data Center (e.g., a center includ- to 
ing one or more processors that hosts various servers 
and other software modules). Traffic from the end sys- 
tem is then routed via a router (connected to the LAN) 
to the public Internet or to an ISP's intranet. The regis- 
tration server located in a foreign WSP's network is re- is 
ferred to as the foreign registration server (FRS), and 
the registration server located in the end system's home 
network (where the mobile purchases its service) is re- 
ferred to as the home registration server (HRS). The in- 
ter-working function unit in the home network is referred 20 
to as the home IWF while the inter-working function unit 
in the foreign network (i.e., the network the end system 
is visiting) is referred to as the serving IWF. 
[0177] For fixed wireless service (i.e., a non-moving 
end system), an end system may register for service on 25 
the home network from the home network (e.g. at home 
service) or from a foreign network (e.g., roaming serv- 
ice). The end system receives, an advertisement sent 
by an agent (e.g. , an agent function implemented in soft- 
ware) in the wireless hub via the access point. There 30 
are both MAC-layer registration as well as network-layer 
registration to be accomplished. These may be com- 
bined together for efficiency. 

[0178] For end systems at home (FIG. 26), the net- 
work layer registration is sent (like a local registration) 35 
to the home registration server via the wireless hub to 
which the end system is currently attached. An IWF in 
the end system's home network will become the anchor 
or home IWF. Thus, PPP frames to and from the end 
system travel via the wireless hub to the home IWF in 40 
the home network. If the end system is at home, the 
home IWF is connected to the wireless hub via an XTun- 
nel protocol. 

[0179] For roaming wireless service (FIG. 27), the for- 
eign registration server determines the identity of the 45 
home network of the roaming end system during the reg- 
istration phase. Using this information, the foreign reg- 
istration server communicates with the home registra- 
tion server to authenticate and register the end system. 
The foreign registration server then assigns a serving so 
IWF, and an l-XTunnel protocol connection is estab- 
lished between the home IWF and the serving IWF for 
the roaming end system. The serving IWF relays frames 
between the wireless hub and the home IWF. From the 
home IWF, data is sent to a PPP server (i.e., point-to- 55 
point protocol server) which may reside in the same IWF. 
However, if the data is to go to a corporate intranet or 
an ISP's intranet that has its own PPP server, the data 



is sent to the separate PPP server via the L2TP protocol. 
The separate server is typically owned and operated by 
an Internet service provider who is different from the 
wireless service provider. For the duration of the ses- 
sion, the locations of the home IWF and PPP server re- 
main fixed. The MAC layer registration can be combined 
with the network registration to economize on the over- 
head of separate communications for MAC layer and 
nenvork layer registration; however, it may be advanta- 
geous to not combine these registration processes so 
that the WSP's equipment will be interoperable with oth- 
er wireless networks that supports pure IETF Mobile-IP. 
[01 80] Registration sets up three tables. Table 1 is as- 
sociated with each access point, and Table 1 identifies 
each connection (e.g., each end system) by a connec- 
tion id (CID) and associates the connection id with a par- 
ticular wireless (WM) modem address (i.e., the address 
of the end system or end system). Table 2 is associated 
with each wireless hub (WH), and Table 2 associates 
each connection id with a corresponding wireless mo- 
dem address, access point and XTunnel id (XI D). Table 
3 is associated with each inter-working function (IWF), 
and Table 3 associates each connection id with a corre- 
sponding wireless modem address, wireless hub ad- 
dress, XTunnel id and IP port (IP/port). The entries de- 
scribed for these tables are described to include only 
relevant entries that support the discussion of mobility 
management. In reality, there are other important fields 
that need to be included as well. 
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Table 3: (continued) 



Connection Table at IWF 
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[0181] The protocol stacks for dial-up users at home 
in a network as well as roaming users are illustrated in 
FIGS. 28-31. FIG. 28 depicts protocol stacks used for 
direct internet access by a fixed (i.e., non-moving) end 
system at home where a PPP protocol message termi- 
nates in the home IWF (typically collocated with the 
wireless hub) which relays message to and from an IP 
router and from there to the public internet. FIG. 29 de- 
^Icts^dtocorsTa^kslJsedTor remote~iritrah et acces sj \T 
e., either private corporate nets or an ISP) by a faced (i. 
e., non-moving) end system at home where a PPP pro- 
tocol message is relayed through the home IWF (typi- 
cally collocated with the wireless hub) to a PPP server 
of the private corporate intranet or ISP FIG. 30 depicts 
protocol stacks used for direct internet access by a 
roaming but fixed (i.e., non-moving) or a moving end 
system where the PPP protocol terminates in the home 
IWF (typically located in a mobile switching center of the 
home network) which relays message to and from an IP 
router. In FIG. 30, note how message traffic passes 
through a serving IWF (typically collocated with the wire- 
less hub) in addition to the home IMF FIG. 31 depicts 
protocol stacks used for remote intranet access (i.e., ei- 
ther private corporate nets or an ISP) by a roaming but 
fixed (i.e., non-moving) or a moving end system where 
a PPP protocol message is relayed through the home 
IWF (typically located in a mobile switching center of the 
home network) to a PPP server of the private corporate 
intranet or ISP. In FIG. 31, note how message traffic 
passes through a serving IWF (typically collocated with 
the wireless hub) in addition to the home IWF. When the 
serving IWF and the wireless hub are co-located in the 
same nest of computers or are even programmed into 
the same computer, it is not necessary to establish a 
tunnel using the XTunnel protocol between the serving 
IWF and the wireless hub. 

[0182] Equivalent variations to these protocol stacks 
(e.g. the RLP can be terminated at the wireless hub rath- 
er than at the serving IWF or home IWF for mobiles at 
home) are also envisioned. If the IWF is located far from 
the wireless hub, and the packets can potentially be car- 
ried over a iossy IP network between the IWF and wire- 
less hub. then it would be preferred to terminate the RLP 
protocol at the wireless hub. Another variation is the 
Xtunnel between wireless hub and IWF need not be built 
on top of the UDP/IP. Xtunnels can be built using the 
Frame Relay/ ATM link layer. However, the use of UDP/ 
IP makes it easier to move the wireless hub and IWF 
software from one network to another. 
[0183] Four types of handoff scenarios may occur 
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and they are labeled: (i) local mobility, (ii) micro mobility 
(iii) macro mobility, and (iv) global mobility In all four 
scenarios (in one embodiment of the invention), a route 
optimization option is not considered so that the loca- 
tions of the home registration server and the ISP's PPP 
server do not change. In another embodiment of the in- 
vention with route optimization, the ISP's PPP server 
may change. However, this aspect is discussed below. 
In addition, the locations of the foreign registration serv- 
er and fWF do not change in the first three scenarios. 
[0184] The proposed IETF Mobile IP standard re- 
quires that whenever an end system changes the IP 
subnet to which it is attached, it sends a registration re- 
quest message to a home agent in its home subnet. This 
message Carries a care-of address where the end sys- 
Jem_can_b.e_reache.d_in-the-ne.w-subnet.-When-traffic-.is- 
sent, for example, from an ISP to an end system, the 
home agent intercepts the traffic that is bound for the 
end system as it arrives in the home subnet, and then 
forwards the traffic to the care-of address. The care-of 
address identifies a particular foreign agent in the for- 
eign subnet. An end system's foreign agent can reside 
in the end system itlelf , or in a separate node that in turn 
forwards traffic to the end system (i.e., proxy registration 
agent). Mobile IP handoffs involve exchange of control 
messages between an end system's agent, the end sys- 
tem's home agent and potentially its corresponding 
hosts (CHs) (with route optimization option). 
[0185] The proposed IETF Mobile IP standard would 
find it difficult to meet the latency and scalability goals 
for all movements in a large internetwork. However, the 
present hierarchical mobility management meets such 
goals. For small movements (e.g. a change of Access 
Points), only MAC-layer re -registrations are needed. 
For larger movements, network-layer re-registrations 
are performed. The present hierarchical mobility man- 
agement is different from the flat-structure used in the 
IETF proposed Mobile-IP standard as well as the serv- 
ing/anchor inter-working function model used in cellular 
systems like CDPD (based on a standard sponsored by 
the Cellular Digital Packet Data forum). 
[0186] As depicted in FIG. 32, the local mobility hand- 
off handles end system (designated MN for mobile 
node) movement between APs that belong to the same 
wireless hub. Thus, only MAC layer re-registration is re- 
quired. The end system receives a wireless hub adver- 
tisement from a new AP and responds with a registration 
request addressed to the new AR 
[0187] The new AP (i.e., the one that receives the reg- 
istration request from the end system) creates new en- 
tries in its connection table and relays the registration 
message to its wireless hub. In local mobility handoffs, 
the wireless hub does not change. The wireless hub rec- 
ognizes the end system's registration request as a MAC 
level registration request , and it updates its connection 
table to reflect the connection to the new AR Then, the 
old AP deletes the connection entry from its connection 
table. There are at least three ways whereby the old AP 
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can delete the old entries, namely (i) upon time out (ii) 
upon receiving a copy of the relayed MAC layer associ- 
ation message from the new AP to the wireless hub (if 
this relay message is a broadcast message), and (iii) 
upon being informed by the wireless hub of the need to 
delete the entry, 

[0188] As depicted in FIG. 33, the micro mobility 
handoff handles end system (designated MN for mobile 
node) movement between wireless hubs hat belong to 
the same registration server and where the end system 
can still be served by the existing serving I WR When an 
advertisement is received from a new wireless hub 
(through a new AP), the end system sends a message 
to request registration to the registration server The reg- 
istration request is relayed from the new AP to the new 
wireless hub to the registration server. 
[0189] When the registration server determines that 
the existing I WF can still be used, the registration server 
sends a build XTunnel Request message to request the 
existing IWF to build an XTunnel to the new wireless 
hub. Later, the registration server sends a tear down 
XTunnel request message to request the existing IWF 
to tear down the existing XTunnel with the old wireless 
hub. The build and tear XTunnel Request messages can 
be combined into one message. A foreign registration 
server does not forward the registration message to the 
home registration server since there is no change of 
IWF, either the serving IWF or home IWF 
[0190] Upon receiving a positive build XTunnel reply 
and a positive tear XTunnel reply from IWF, the regis- 
tration server sends a registration reply to end system. 
As the registration reply reaches the new wireless hub, 
the connection table at the new wireless hub is updated 
to reflect the connection to the new AP The new AP up- 
dates its MAC filter address table and connection table 
after receiving a message from the new wireless hub, 
and the registration reply is forwarded to the end sys- 
tem. 

[0191] The registration server sends a release mes- 
sage to the old wireless hub. When the old wireless hub 
receives the release message, it updates its connection 
table and the MAC filter address table and connection 
table of the old AP. 

[0192] As depicted in FIG. 34, the macro mobility 
handoff case handles movement between wireless hubs 
that involves a change of the serving IWF in the foreign 
network, but it does not involve a change in the regis- 
tration server. When an advertisement is received from 
a new wireless hub (through a new AP), the end system 
sends a message to request a network layer registration 
to the registration server. The registration request is re- 
layed from the new AP to the new wireless hub to the 
registration server. 

[0193] The registration server recognizes that it is a 
foreign registration server when the end system does 
not belong to the present registration server's network. 
This foreign registration server determines the identity 
of the home registration server by using a request, pref- 
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erably a Radius Access request (RA request), to the for- 
eign directory server (like a big yellow pages) and then 
assigns an appropriate IWF to be the serving IWF and 
it forwards a registration request to the home registra- 
5 tion server, preferably through a Radius Access request 
(RA request), informing the home registration server of 
the newly selected IWF 

[01 94] The home registration server authenticates the 
registration request by using a request, preferably a Ra- 

10 dius Access request (RA request), to the home directory 
server. Upon authenticating the request and determin- 
ing that the existing home IWF can still be used., the 
home registration server instructs the home IWF to build 
a new l-XTunnet to the newly assigned serving IWF and 

is to tear down the existing I -XTunnel to the old serving 
IWF. Upon receiving a positive build l-XTunnel reply and 
a positive tear l-Xtunnel reply from the home IWF, the 
home registration server sends a registration reply to the 
foreign registration server. 

20 [0195] The foreign registration server then instructs 
the newly assigned IWF to build an XTunnel to the new 
wireless hub. Upon receiving a positive build XTunnel 
reply, the foreign registration server instructs the old 
IWF to tear down the XTunnel to the old wireless hub. 

25 Upon receiving a positive build XTunnel reply and a pos- 
itive tear xTunnel reply, the foreign registration server 
sends a registration reply to end system. 
[0196] As the registration reply reaches the new wire- 
less hub, the connection table at the new wireless hub 

30 is updated to reflect the connection to the new AP. The 
new AP updates its MAC filter address table and con- 
nection table after receiving a message from the new 
wireless hub, and the registration reply is forwarded to 
the end system. 

35 [0197] The registration server sends a release mes- 
sage to the old wireless hub, When the old wireless hub 
receives the release message, it updates its connection 
table and the MAC filter address table, and the old AP 
updates its MAC filter address table and connection ta- 

40 ble after receiving a message from the old wireless hub. 
[0198] The global mobility handoff case handles 
movement between wireless hubs that involves a 
change of registration servers. FIG. 35 depicts a global 
mobility handoff where the home IWF does not change, 

45 and FIG. 36 depicts a global mobility handoff where the 
home IWF changes. When an advertisement is received 
from a new wireless hub (through a new AP) in a new 
foreign network, the end system sends a message to 
request a network layer registration to the new foreign 

50 registration server. The registration request is relayed 
from the new AP to the new wireless hub to the new 
foreign registration server. 

[0199] The registration server recognizes that it is a 
new foreign registration server when the end system 
55 does not belong to the present registration server's net- 
work. This foreign registration server determines the 
identity of the home registration server by using a re- 
quest, preferably a Radius Access request (RA re- 
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quest), to the foreign directory server (like a big yellow 
pages) and then assigns an appropriate IWF to be the 
serving IWF, and it forwards the registration request to 
the home registration server, preferably through a Ra- 
dius Access request (RA request), informing the home 
registration server of the newly selected IWF 
[0200] The home registration server authenticates the 
registration request by using a request, preferably a Ra- 
dius Access request (RA request), to the home directory 
server. Upon authenticating the request and determin- 
ing that the existing home IWF can still be used (FIG. 
35), the home registration server instructs the home IWF 
to build a new l-XTunnel to the serving IWF newly as- 
signed by the new foreign registration server. The home 
registration server also sends a de-registration mes- 
jsag ejQlh e old foreign regist rati on„s_e rye r a nd J n .s.tru c.ts_ 
the home IWF to tear down the existing l-XTunnel to the 
existing serving IWF of the old foreign network, Upon 
receiving a positive build l-XTunnel reply and a positive 
tear l-XTunnel reply from the home IWF, the home reg- 
istration server sends a registration reply to the new for- 
eign registration server. 

[0201] The new foreign registration server then in- 
structs the newly assigned IWF to build an XTunnel to 
the new wireless hub. Upon receiving a positive build 
XTunnel reply, the foreign registration server sends a 
registration reply to end System. As the registration re- 
ply reaches the new wireless hub, the connection table 
at the new wireless hub is updated to reflect the con- 
nection to the new AP. The new AP updates its MAC 
filter address table and connection table after receiving 
a message from the new wireless hub, and the registra- 
tion reply is forwarded to the end system. 
[0202] The old foreign registration server instructs the 
old IWF to tear down the XTunnel to the old wireless 
hub. Upon receiving a positive tear XTunnel reply or 
contemporaneously with the tear down XTunnel re- 
quest, the old foreign registration server sends a release 
message to the old wireless hub. When the old wireless 
hub receives the release message, it updates its con- 
nection table and the MAC filter address table, and the 
old AP updates its MAC filter address table and connec- 
tion table after receiving a message from the old wire- 
less hub. 

[0203] Alternatively, after the home registration server 
authenticates the registration request from the new for- 
eign registration server and determines that the existing 
home IWF cannot be used (FIG. 36), the home registra- 
tion server chooses a new home IWF and instructs the 
new home IWF to build a new level 2 tunnel protocol 
tunnel (L2TP tunnel) to the present PPP server (e.g., 
the PPP server in a connected ISP intranet). Then, the 
home registration server instructs the old home IWF to 
transfer its L2TP tunnel traffic to the new home IWF. 
[0204] Then the home registration server instructs the 
new home IWF to build a new l-XTunnel to the serving 
IWF newly assigned by the new foreign registration 
server. The home registration server also sends a de- 



registration message to the old foreign' registration 
server and instructs the home IWF to tear down the ex- 
isting l-XTunnel to the existing serving IWF of the old 
foreign network. Upon receiving a positive build l-XTun- 

5 nel reply and a positive tear l-XTunnel reply from the 
home IWF, the home registration server sends a regis- 
tration reply to the new foreign registration server. 
[0205] The new foreign registration server then in- 
structs the newly assigned IWF to build an XTunnel to 

10 the new wireless hub. Upon receiving a positive build 
XTunnel reply, the foreign registration server sends a 
registration reply to end system. As the registration reply 
reaches the new wireless hub, the connection table at 
the new wireless hub is updated to reflect the connection 

is to the new AP. The new AP updates its MAC filter ad- 
~ dress tableland-connection ~table-after~receiving-a ^mes- 
sage from the new wireless hub, and the registration re- 
ply is forwarded to the end system. 
[0206] The old foreign registration server instructs the 

20 old IWF to tear down the XTunnel to the old wireless 
hub. Upon receiving a positive tear XTunnel reply or 
contemporaneously with the tear down XTunnel re- 
quest, the old foreign registration server sends a release 
message to the old wireless hub. When the old wireless 

25 hub receives the release message, it updates its con- 
nection table and the MAC filter address table, and the 
old AP updates its MAC filter address table and connec- 
tion table after receiving a message from the old wire- 
less hub. 

30 [0207] End systems constructed according to the 
present invention interoperate with networks construct- 
ed according to the proposed. IETF Mobile-IP stand- 
ards, and end systems constructed according to the pro- 
posed IETF Mobile-IP standards interoperate with net- 

35 works constructed according to the present invention. 
[0208] The main differences between the present in- 
vention and the IETF Mobile-IP (RFC2002, a standards 
document) are: 



40 



45 



50 



55 



(i) The present invention uses a hierarchical con- 
cept for mobility management rather than a flat 
structure as in the proposed IETF Mobile-IP stand- 
ard. Small mobility within a small area does not re- 
sult in a network level registration. Micro mobility in- 
volves setting up of a new Xtunnel and tearing down 
of an existing Xtunnel. Global mobility, at the mini- 
mum, involves setting up of new l-XTunnel and tear- 
ing down of an existing l-Xtunnel apart from the set- 
ting up/tearing down of XTunnel. Global mobility 
sometimes also involves setting up a new L2TP 
Tunnel and transferring of L2TP state from the ex- 
isting L2TP Tunnel to the new L2TP Tunnel. 

(ii) In the present invention, a user name plus a 
realm is used to identify a remote dial-up user rather 
than a fixed home address as in the case of the pro- 
posed IETF Mobile-IP standard. 
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(iii) In the present invention, registration and routing 
functions are carried out by separate entities. The 
two functions are carried out by the home agent in 
the proposed IETF Mobile IP standard, and both 
functions are carried out by the foreign agent in the 
proposed I EFT Mobile IP standard. In contrast, in 
an embodiment of the present invention, registra- 
tion is carried out in the registration server and rout- 
ing functions are carried out by both the home and 
foreign IWF and the wireless hub (also referred to 
as the access hub). 

(iv) The present invention utilizes three tunnels per 
PPP session. The XTunnel is more of a link-layer 
tunnel between the wireless hub and the serving 
IWF. The l-XTunnel between the serving IWF and 
the home IWF is more like the tunnel between home 
and foreign agents in the proposed IETF Mobile-IP 
standard. But it also has additional capabilities be- 
yond the tunnels proposed by the Mobile-IP stand- 
ard. The L2TP tunnel is used only when home IWF 
is not a PPP server. The number of these tunnels 
may be reduced by combining some functions in the 
same node as described above. 

(v) In the present invention, wireless registration oc- 
curs before PPP session starts while in the pro- 
posed IETF Mobile-IP standard, Mobile-IP registra- 
tion occurs after PPP session enters into the open 
state. 

(vi) In the present invention, the network entity that 
advertises the agent advertisement (i.e., the wire- 
less hub) is not on a direct link to the end systems 
whereas for the proposed IETF Mobile-IP standard, 
the agent advertisement must have a TTL of 1 
which means that the end systems have a direct link 
with the foreign agent. In addition, the agent adver- 
tisement in the present invention is not an extension 
to the ICMP router advertisements as in the pro- 
posed IETF Mobile-IP standard. 

[0209] End systems in the present invention, should 
support agent solicitation. When an end system in the 
present invention visits a network which is supporting 
the proposed IETF Mobile-IP standard, it waits until it 
hears an agent advertisement. If it does not receive an 
agent advertisement within a reasonable time frame, it 
broadcasts an agent solicitation. 

[0210] In the present invention, network operators 
may negotiate with other networks that support the pro- 
posed IETF Mobile-IP standard such that home ad- 
dresses can be assigned to the end systems of the 
present invention that wish to use other networks. When 
the end system of the present invention receives the 
agent advertisement, it can determine that the network 
it is visiting is not an a network according to the present 
invention and hence uses the assigned home address 



to register. 

[0211] For networks supporting the proposed IETF 
Mobile-IP standard, the PPP session starts before Mo- 
bile-IP registration, and the PPP server is assumed to 
5 be collocated with the foreign agent in such networks. 
In one embodiment an SNAP header is used to encap- 
sulate PPP frames in the MAC frames of the present 
invention (in a manner similar to Ethernet format), and 
the foreign agent interprets this format as a proprietary 

w ppp format over Ethernet encapsulation. Thus, the end 
system of the present invention and its PPP peer can 
enter into an open state before the foreign agent . starts 
transmitting an agent advertisement, and the end sys- 
tem of the present invention can register. 

1 $ [0212] To allow end systems supporting the proposed 
IETF Mobile-IP standard to work in networks of the type 
of the present invention, such mobiles are at least ca- 
pable of performing similar MAC layer registrations. By 
making the agent advertisement message format simi- 

20 (ar to the proposed Mobile-IP standard agent advertise- 
ment message format, a visiting end system can inter- 
pret the agent advertisement and register with a wire- 
less hub. In the present invention, registration request 
and reply messages are similar to the proposed IETF 

25 Mobile-IP standard registration request and reply, mes- 
sages (without any unnecessary extensions) so that the 
rest of the mobility management features of the present 
invention are transparent to the visiting end systems. 
[0213] Since end systems supporting the proposed 

30 IETF Mobile-IP standard expect a PPP session to start 
before Mobile-IP registration, an optional feature in wire- 
less hubs of the present invention starts to interpret PPP 
LCP, NCP packets after MAC-layer registrations. 
[0214] To avoid losing traffic during handoffs, the mo- 
ss bility management of the present invention uses the 
make before break concept. For local mobility, a make 
before break connection is achieved by turning the 
MAC-layer registration message relayed by the new AP 
to the wireless hub into a broadcast message. That way, 

^0 the old AP can hear about the new registration and for- 
ward packets destined for the end system that have not 
been transmitted to the new AP 

[0215] For micro mobility, information about the new 
wireless hub is included in the Tear XTunnel message 

45 exchanged between the serving IWF and the old WH. 
That way, the old wireless hub can forward buffered 
packets to the new wireless hub upon hearing a TearX- 
Tunnel message from the serving IWF. Alternatively, the 
RLP layer at the IWF knows the sequence number that 

50 has been acknowledged by the old wireless hub so far. 
[0216] At the same time, the IWF knows the current 
send sequence number of the latest packet sent to the 
old wireless hub. Therefore, the IWF can forward those 
packets that are ordered in between these two numbers 

55 to the new wireless hub before sending newer packets 
to the new wireless hub. The RLP layer is assumed to 
be able to filter duplicate packet. The second approach 
is probably preferable to the first approach for the old 
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wireless hub may not be able to communicate with one 
another directly. 

[0217] For macro mobility, the old serving IWF can for- 
ward packets to the new serving IWF, in addition to the 
packet forwarding done from the old wireless hub to the 
new wireless. All we need to do is to forward the new 
serving IWF identity to the new serving IWF in the tear 
down l-XTunnel message. Another way to achieve the 
same result is to let the home IWF forward the missing 
packets to the new serving IWF rather than asking the 
old serving IWF to do the job since the home IWF knows 
the l-XTunnel sequence number last acknowledged by 
the old serving IWF and the current l-XTunnel sequence 
number sent by the home IWF. 

[0218] The method of estimating how much buffer 
-should be allocated-per mobile-per-AP-per-wireless hub- 
per IWF such that the traffic loss between handoffs can 
be minimized is to let the end system for the AP for the 
wireless hub for the IWF estimate the packet arrival rate 
and the handoff time. This information is passed to the 
old AP of the wireless hub of the IWF to determine how 
much traffic should be transferred to the new AP of the 
wireless hub of the IWF, respectively, upon handoffs. 
[0219] To achieve route optimization in the present in- 
vention, the end system chooses the PPP server closest 
to the serving IWP Without route optimization, exces- 
sive transport delays and physical line usage may be 
experienced. 

[0220] For example, an end system subscribed to a 
home network in New York City may roam to Hong Kong. 
To establish a link to a Hong Kong ISP, the end system 
would have a serving IWF established in a wireless hub 
in Hong Kong and a home IWF established in the home 
network in New York City. A message would then be 
routed from the end system (roamed to Hong Kong) 
through the serving IWF (in Hong Kong) and through the 
home IWF (in New York City) and back to the Hong Kong 
ISP. 

[0221] A preferred approach is to connect from the 
serving IWF (in Hong Kong) directly to the Hong Kong 
ISP. The serving IWF acts like the home IWF. In this em- 
bodiment, roaming agreements exist between the home 
and foreign wireless providers. In addition, the various 
accounting/billing systems communicate with one an- 
other automatically such that billing information is 
shared. Accounting and billing information exchange 
may be implement using standards such as the stand- 
ard proposed by the ROAMOPS working group of the 
IETF. 

[0222] However, the serving IWF must still discover 
the closest PPP server (e.g. the Hong Kong ISP). In the 
present embodiment, the foreign registration server 
learns of the end system's desire to connect to a PPP 
server (e.g., a Hong Kong ISP) when it receives a reg- 
istration request from the end system. When the foreign 
registration server determines that the serving IWF is 
closer to the desired PPP server (e.g., the Hong Kong 
ISP) than the home IWF is, the foreign registration serv- 



er instructs the serving IWF to establish an L2TP tunnel 
to its nearest PPP server (in contrast to the PPP server 
closest to the home registration server and home IWF). 
Then, the foreign registration server informs the home 

5 registration server that the end system is being served 
by the serving IWF and the foreign PPP. 
[0223] In an alternative embodiment, the foreign reg- 
istration server determines that the serving IWF is closer 
to the desired PPP server (e.g., the Hong Kong ISP) 

10 than the home IWF is, when it receives a registration 
request from the end system. The foreign registration 
server relays the registration request message to the 
home registration server with an attached message in- 
dicating the serving IWF information and a notification 

15 that route optimization is preferred. At the same time, 
— — the-foreign-registration-serveHnstruets-the-servtng I WF- 
to establish an L2TP tunnel to the PPP server. Upon ap- 
proving the registration request, the home registration 
server instructs the home IWF to transfer the L2TP state 

20 to the foreign IWF. 

[0224] Having described preferred embodiments of a 
novel network architecture with wireless end users able 
to roam (which are intended to be illustrative and not 
limiting), it is noted that modifications and variations can 

25 be made by persons skilled in the art in light of the above 
teachings. For example, connection links described 
herein may make reference to known connection proto- 
cols (e.g., IP, TCP/IP, L2TP, IEEE 802.3, etc.); however, 
the invention contemplates other connection protocols 

30 in the connections links that provide the same or similar 
data delivery capabilities. Acting agents in the above de- 
scribed embodiments may be in the form of software 
controlled processors or may be other form of controls 
(e.g., programmable logic arrays, etc.). Acting agents 

35 may be grouped as described above or grouped other- 
wise in keeping with the connection teachings described 
herein and subject to security and authentication teach- 
ings as described herein. Furthermore, a single access 
point, access hub (i.e., wireless hub) or into-working 

40 function unit (IWF unit) may provide multi-channel ca- 
pability. Thus, a single access point or access hub or 
IWF unit may act on traffic from multiple end systems, 
and what is described herein as separate access points, 
access hubs or IWF units contemplates equivalence 

45 with a single multichannel access point, access hub or 
IWF unit. It is therefore to be understood that changes 
may be made in the particular embodiments of the in- 
vention disclosed which are within the scope and spirit 
of the invention as defined by the appended claims. 

so 

Claims 

1. A coupled data network comprising: 

55 

a foreign network that includes a base station 
and a foreign mobile switching center with a 
serving registration server, the base station in- 
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eluding an access hub with a serving inter- 
working function; 

a home network that includes a home mobile 
switching center with a home registration serv- 
er and a home inter-working function; and 5 
an end system subscribed to the home network 
and operating within the foreign network, the 
end system including an end registration agent 
to form a registration request, the registration 
request including an indication of a desired- to 
communications network having a desired 
communications server, the end system send- 
ing the registration request to the serving reg- 
istration server, the serving registration server 
including a first module to process the registra- is 
tion request and to determine an optimum route 
between the desired communications server 
and one of the home inter-working function and 
the serving inter-working function, the serving 
registration server further including a second 20 
module to link the serving inter-working func- 
tion to the desired communications server 
when the first module determines that the opti- 
mum route is between the serving inter-working 
function and the desired communications serv- 2s 
er. 

2. The data network of claim 1 , wherein the serving 
registration server further includes a third module 

to send to the home registration server the registra- 30 
tion request with an appended indication that the 
service registration server has linked the serving in- 
ter-working function and the desired communica- 
tions server. 

35 

3. A coupled data network comprising: 

a foreign network that includes a base station 
and a foreign mobile switching center with a 
serving registration server, the base station in- 40 
eluding an access hub with a serving inter- 
working function; 

a home network that includes a home mobile 
switching center with a home registration serv- 
er and a home inter-working function; and 45 
an end system subscribed to the home network 
and operating within the foreign network, the 
end system including an end registration agent 
to form a registration request, the registration 
request including and indication of a desired so 
communications network having a desired 
communications server, the end system send- 
ing the registration request to the serving reg- 
istration server, the serving registration server 
including a first module to process the registra- ss 
tion request and to determine an optimum route 
between the desired communications server 
and one of the home inter-working function and 
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the serving inter-working function, the serving 
registration server further including a second 
module to send to the home registration server 
the registration request with a first appended 
indication that the serving registration server 
has determined that the optimum route is be- 
tween the serving inter-working function and 
the desired communications server and a sec- 
ond appended indication that route optimiza- 
tion is preferred. 

4. The data network of claim 3, wherein the serving 
registration server includes a third module to estab- 
lish a link between the serving inter-working func- 
tion and the desired communications processor af- 
ter sending the registration request and the first and 
second appended indications to the home registra- 
tion server. 

5. The data network of claim 4, wherein: 

the home registration server includes a fourth 
module to send a registration reply to the serv- 
ing registration server, the registration reply in- 
cluding an indication of that the link between 
the serving inter-working function and the de- 
sired communications server is approved; and 
the home registration server further includes a 
fifth module to instruct the home inter-working 
function to transfer a link state to the serving 
inter- working function. 

6. A method for optimizing routing in a coupled data 
network wherein the coupled data network compris- 
es a foreign network that includes a base station 
and a foreign mobile switching center with a serving 
registration server, the base station including an ac- 
cess hub with a serving inter-working function, a 
home network that includes a home mobile switch- 
ing center with a home registration server and a 
home inter-working function, and an end system 
subscribed to the home network and operating with- 
in the foreign network, the end system including an 
end registration agent to form a registration request, 
comprising the steps of: 

generating a registration request at the end 
system, said registration request including an 
indication of a desired communications net- 
work having a desired communications server; 
sending the registration request from the end 
system to the serving registration server; 
processing the registration request in a first 
module in the serving registration server to de- 
termine an optimum route between the desired 
communications server and one of the home in- 
ter-working function and the serving inter-work- 
ing function; 
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linking the serving inter-working function to the 
desired communications server when the first 
module determines that the optimum route is 
between the serving inter-working function and 
the desired communications server. 5 

7. The method of claim 6, further comprising the step 
of: 

sending to the home registration server the 
registration request with an appended indication 10 
that the service registration server has linked the 
serving inter-working function and the desired com- 
munications server 
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function is closer to the desired communica- 
tions server than the home inter-working func- 
tion; 

informing the home registration server that the 
end system is being served by the serving inter- 
working function and the desired communica- 
tions server. 



8. The method of claim 6 or the network of claim 1 or 1$ 

— _claim-3-wherein;— — ________ — ___ ___ 



the desired communications server is one com- 
munication server of a plurality of communica- 
tions servers in the desired communications 20 
network; and 

the first module includes a sub-module to de- 
termine the select the desired communications 
server from among the plurality of communica- 
tions servers. 25 



9. The method of claim 6 or the network of claim 1 or 
claim 3 , wherein said home network and said for- 
eign network share billing information for the end 
system when the end system is operating in the for- 30 
eign network. 



10. A method for optimizing routing in a coupled data 
network wherein the coupled data network compris- 
es a foreign network that includes a base station 35 
and a foreign mobile switching center with a serving 
registration server, the base station including an ac- 
cess hub with a serving inter-working function, a 
home network that includes a home mobile switch- 
ing center with a home registration server and a 40 
home inter-working function, and an end system 
subscribed to the home network and operating with- 
in the foreign network, the end system including an 
end registration agent to form a registration request, 
comprising the steps of: 45 

generating a registration request at the end 
system, said registration request including an 
indication of a desired communications net- 
work having a desired communications server; so 
sending the registration request from the end 
system to the serving registration server; 
determining whether the server inter-working 
function or the home inter-working function is 
closer to the desired communications server; 55 
instructing the serving inter-working function to 
establish a connection to the desired commu- 
nications server when the serving inter-working 
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